royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <>
Subject Re: My finding using Apache Royale and 3 points I'd like to get addressed
Date Wed, 05 Sep 2018 10:22:52 GMT
Hi Carlos,

#1 I’m not sure I understand what you’re saying in #1. Can you give some concrete examples
of what you’re saying? I think it’ll help me understand.

#2: The few times I tried playing with Royale states, I get confused pretty quickly. I’d
have to spend some time to understand your point here.

#3 I agree that it would be good to have some more decoration to handle setting setting things
like display and overflow. I don’t want to *require* it be handled by CSS classes, but it
would be good to decouple the code to make it possible to handle it in css classes without
messy subclassing and the like. I’m not sure how to best architecture that concept.


> On Sep 5, 2018, at 12:50 PM, Carlos Rovira <> wrote:
> Hi,
> after report the differences between versions (w/wout Basic), I want to go
> further and comment my experiences to the date with Apache Royale in
> general and what I'm finding.
> I think Royale is now getting more mature and mostly we can do many things.
> I'm very confortable with all what Apache Royale can do and I think it has
> many amazing things build into it.
> And mostly I appreciate how well crafted are many parts of this framework.
> The points where I'm finding more problems are more in the UX/UI side, but
> are related to code design:
> 1.- *Still I have many issues when trying to deal with class selectors*. I
> think the main problem is that we don't have good support in UIBase, and we
> try to compose it, but the result of this is that we're getting in Jewel
> many classes that are relating code (not PAYG at all) to get something that
> I think should be inherent to each UIBase. In other words, class names are
> not optional. Are prime citizens and we should have it with out the need of
> compose nothing, since is something almost every user will need. Not
> something only some people will use.
> Optional way to deal with this could be to add a bead vía CSS that gives
> this functionality, so UIBase, Group, Container, DataContainer, and so on,
> could have this. But sincerely, I think it would cost more the collar than
> the dog.
> So my first proposal, will be get rid of Styled*-* classes I introduced and
> make Royale play nicely with class selectors.
> 2.- *States have a problem with class names*. Due to point 1, when you use
> class names in Royale and states, most of the time you'll loose class
> names, when Royale recreates the state. Most of the time this happens with
> class selector based layouts, since are modifying the strand set of
> classes. Whatever bead that change class selectors in strand will fin this
> problem.
> We now have typeNames and className. I think Alex already mentioned that we
> need another var sit up in and intermediate point so UIBase components
> could know about what are the actual configuration. Maybe layouts and other
> classes will put the class names in this var so when changing states this
> var will be take into account to set the state equal as how it was before
> the change.
> This problem is very cumbersome, and you can fin it in this example:
> (but not in the published one, but in the one that you compile locally)
> 3.- Many times I find lines in the main code of a component like:
> = "block";
> or
> = "hidden";
> Hardcoding this kind of things in a class limit our code. If we decouple it
> to css, will have the possibility of:
> 1.- remove some code extensions (at least in Jewel, since I have to extend
> to remove this kind of things)
> 2.- will make the code more reusable since will play nicely with the rest
> of code in CSS we have.
> only when we have to deal with dynamic values, we should write that kind of
> code (i.e: changing x or y based on a value).
> As I said, all the problems are more related to styling, and maybe is since
> here we're more coders than designers, but we must to remember that Royale
> is about "presentation" and we should have the less possible walls to
> designers since this kind of developers could come to Royale and use it at
> some time, but this limitations make this difficult. In my case, I consider
> me a hybrid developer, and can deal with some problems, but if I'm finding
> this problems sometimes difficult to deal with.
> I tried to put this 3 problems in order of importance.
> Thoughts?
> -- 
> Carlos Rovira

View raw message