My finding using Apache Royale and 3 points I'd like to get addressed

[Carlos Rovira <ca...@apache.org>]

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:

https://royale.apache.org/using-view-states-to-show-or-hide-content/

(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:

element.style.display = "block";
or
element.style.overflow = "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
http://about.me/carlosrovira

Re: My finding using Apache Royale and 3 points I'd like to get addressed

[Carlos Rovira <ca...@apache.org>]

I forgot a 4 point:

4.- Our support for CSS in compiler needs to be improved:

we still can't use many CSS things since compiler fail at some point, when
doing Jewel I tried to find alternative paths, but sometimes this are not
possible.
For example:
* for animation: @keyframe or cubil-bezier are not supported
* css selectors in brackets like NOT and other are very needed and used
widely, we only support some of them
https://www.w3schools.com/cssref/css_selectors.asp

and more

I think this is important, in the day-to-day basis for our users (well, in
fact for me too! :))

Thanks





El mié., 5 sept. 2018 a las 11:50, Carlos Rovira (<ca...@apache.org>)
escribió:

> 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:
>
> https://royale.apache.org/using-view-states-to-show-or-hide-content/
>
> (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:
>
> element.style.display = "block";
> or
> element.style.overflow = "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
> http://about.me/carlosrovira
>
>

-- 
Carlos Rovira
http://about.me/carlosrovira

Re: My finding using Apache Royale and 3 points I'd like to get addressed

[Carlos Rovira <ca...@apache.org>]

ok Harbs, waiting for your experiment

El mié., 5 sept. 2018 a las 14:03, Harbs (<ha...@gmail.com>) escribió:

> I have another idea which is probably best expressed in code.
>
> I’ll see if I can find some time to show…
>
> > On Sep 5, 2018, at 2:40 PM, Carlos Rovira <ca...@apache.org>
> wrote:
> >
> >> #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.
> >>
> >
> > two options:
> > 1.- have some key css class selectors. I think they are not too much
> (i.e:
> > for overflow, cursor, display...) that will be inherent to Royale. Is the
> > right way to decouple for me.
> >
> > 2.- move that code to methods and subclass removing that code (don't like
> > this too much and continue to address the decoupling)
>
>

-- 
Carlos Rovira
http://about.me/carlosrovira

Re: My finding using Apache Royale and 3 points I'd like to get addressed

[Harbs <ha...@gmail.com>]

I have another idea which is probably best expressed in code.

I’ll see if I can find some time to show…

> On Sep 5, 2018, at 2:40 PM, Carlos Rovira <ca...@apache.org> wrote:
> 
>> #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.
>> 
> 
> two options:
> 1.- have some key css class selectors. I think they are not too much (i.e:
> for overflow, cursor, display...) that will be inherent to Royale. Is the
> right way to decouple for me.
> 
> 2.- move that code to methods and subclass removing that code (don't like
> this too much and continue to address the decoupling)

Re: My finding using Apache Royale and 3 points I'd like to get addressed

[Carlos Rovira <ca...@apache.org>]

Hi Harbs

El mié., 5 sept. 2018 a las 12:23, Harbs (<ha...@gmail.com>) escribió:

> 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.
>

Since UIBase is the parent of almost all components in Royale, I can have a
StyledUIBase with the addClass, removeClass, and so on... but if you go to
Jewel Group, then you have the same, html Group comes from UIBase, not
StyledUIBase, so you have to replicate the structure or create StyledGoup,
then the same for Container, DataGroup, DataContainer, and so on...

So UIBase doesn't have addClass, removeClass, for PAYG, but we are getting
the opposite duplicating this code in all code "branches", instead of
having in the "root".
Hope this helps


>
> #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.
>
>
This is a feature all our users wants, and when we published the blog
Royale example, it generate many noise for us, so this will be something
people will go directly to use.

The problem I see is that since it seems to play nicely in general, class
names are loosed, Maybe Alex could bring here some light on how things are
stored and retrieved.


> #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.
>

two options:
1.- have some key css class selectors. I think they are not too much (i.e:
for overflow, cursor, display...) that will be inherent to Royale. Is the
right way to decouple for me.

2.- move that code to methods and subclass removing that code (don't like
this too much and continue to address the decoupling)

Don't find more options...

Thanks


>
> Harbs
>
>
> > On Sep 5, 2018, at 12:50 PM, Carlos Rovira <ca...@apache.org>
> 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:
> >
> > https://royale.apache.org/using-view-states-to-show-or-hide-content/
> >
> > (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:
> >
> > element.style.display = "block";
> > or
> > element.style.overflow = "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
> > http://about.me/carlosrovira
>
>

-- 
Carlos Rovira
http://about.me/carlosrovira

Re: My finding using Apache Royale and 3 points I'd like to get addressed

[Harbs <ha...@gmail.com>]

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.

Harbs


> On Sep 5, 2018, at 12:50 PM, Carlos Rovira <ca...@apache.org> 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:
> 
> https://royale.apache.org/using-view-states-to-show-or-hide-content/
> 
> (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:
> 
> element.style.display = "block";
> or
> element.style.overflow = "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
> http://about.me/carlosrovira