You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-dev@incubator.apache.org by Adam Winer <aw...@gmail.com> on 2006/08/17 16:00:23 UTC
Button skinning (was Re: [Proposal] Skin hooks for mouseOver and onPress)
Oh, that...
That opens up a new topic: what the heck should we do about
Trinidad button skinning?
As a little background: ADF Faces had a large image-generation
subsystem code-named "Tecate" that took text, metadata, and
other images, and composited them into single images. This
let us have fancy-looking buttons containing, for example,
translatable text. Instead of trying to get thousands of button
images translated (which would have been a nightmare), developers
just got text translated as normal and Tecate did the heavy lifting
at runtime.
It was used for more than buttons - tabs and "global buttons" (now
hint="buttons" on navigationPane) also went through this system.
At a certain point, we decided this was just a bad idea, and that a
better approach was a straightforward HTML and CSS skinning
approach. So, most of the code moved away from Tecate.
As of Trinidad, though, buttons were still left on it. And, as a result,
we have the large org.apache.myfaces.trinidadinternal.image package -
and all of the code in there - just for one simple feature.
I'd really like to come up with a simpler button skinning strategy,
and kill the "image" package altogether. The simplest possible
strategy is just HTML along the lines of:
<button class="af_commandButton>...</button>
-- Adam
On 8/17/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
>
> Unless those exist and are not documented it would not work because the
> button image is composed of 8 part, one background and one text all merged
> together in a single image. So using CSS :hover and :active on the 9
> selectors would not work. Furthermore if I remember well :hover and
> :active works only for links under IE.
>
> Maybe those are managed by the skin already but I never figured it out
> though. Jeanne, can you confirm please?
>
>
> ¬Simon
>
>
>
>
>
> "Adam Winer" <aw...@gmail.com>
> 2006-08-16 16:47
> Please respond to adffaces-dev
>
> To: adffaces-dev@incubator.apache.org
> cc:
> Subject: Re: [Proposal] Skin hooks for mouseOver and
> onPress
>
>
> Isn't this just :hover and :active?
>
> -- Adam
>
>
> On 8/16/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> > Hello all,
> >
> > I just had a flashback from my ADF Faces project. In that project we
> > wanted to use a different image on mouse over event. In the end we had
> to
> > use commandLink with an image and some JavaScript events instead. So my
> > suggestion about button would be to add skin state hooks for mouseOver
> and
> > mouseDown occuring on buttons to improve their L&F and thus user
> > experience.
> >
> > ¬Simon
> >
>
>
>
Re: Button skinning (was Re: [Proposal] Skin hooks for mouseOver and
onPress)
Posted by Si...@DMR.CA.
Well I didn't play with width, but with a div, the background-image get
extended to the parent component width, which is bad if it's the body
itself. For span, I didn't play much with the width/border/margin/padding
but the image was getting streched on a larger width than the button as
well.
It's true that image package takes huge space, but removing it might get
lot of complains from ADF Faces users wanting to swith over to Trinidad.
"Adam Winer" <aw...@gmail.com>
2006-08-17 18:49
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject: Re: Button skinning (was Re: [Proposal] Skin hooks
for mouseOver and onPress)
On 8/17/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
>
> I just tested those style classes, they're prety nice.However, I think
the
> results are better with simply the following
>
> .ButtonCellIE
> {
> margin: 0px;
> padding: 0px;
> background-image: url(background.jpg);
> }
>
> .ButtonStyleIE
> {
> background-color: transparent;
> }
>
> .ButtonCellFirefox
> {
> margin: 0px;
> padding: 0px;
> }
>
> .ButtonStyleFirefox
> {
> background-image: url(background.jpg);
> }
>
>
> It seems that Firefox supports button background-images natively, it
works
> even without the cell and the result is better oveall. Sadly div does
not
> work well.
In FireFox? Hrm, I've used background-images on divs in Firefox and IE,
and had it worked in both.
This solution also has its drawback since you cannot use round borders.
> For buttons it might not be a huge issue, but navigationPane might hurt,
> especially for tabs. So until we can provide users with an equal
> flexibility system for tabs I will be
>
> -1 on removing image package
> +1 on removing button dependancy toward image package.
>
If the button code doesn't depend on it, then it's a lot of code
that isn't used at all... it's in the Subversion repository, so anyone
so inclined could always resurrect it for a given purpose, but I'd
rather kill it until someone actually wants it.
-- Adam
¬ Simon
>
>
>
>
>
>
> Jeanne Waldman <je...@oracle.com>
> 2006-08-17 12:55
> Please respond to adffaces-dev
>
> To: adffaces-dev@incubator.apache.org
> cc:
> Subject: Re: Button skinning (was Re: [Proposal] Skin
hooks
> for mouseOver and onPress)
>
>
> We had a customer that wanted to put background images on our buttons.
> He couldn't do this with our buttons unless they had a container
> (I haven't tested this in ages, but I remember that he was right), so
what
> he did was wrap our command button in a afh:cellFormat and put a
> styleClass on both.
> The problem was that he couldn't style buttons that were rendered as a
> part
> of another component, so some of his buttons had a gradient background
and
> some didn't.
>
> I recommend that we wrap our <button> html tag with
> a <div> or something so that the skinner can put background images on
the
> buttons.
>
> The following is how he skinned the commandButton:
>
>
> .ButtonCell
> {
> margin: 0px; padding: 0px;
> border-top: 1px solid #afc6d7; border-left: 1px solid #afc6d7;
> border-bottom: 1px solid #666666; border-right: 1px solid #666666;
> background-repeat: repeat-x; background-position: bottom left;
> background-color: #ffffff;
> text-align: center;
> vertical-align: middle;
> background-image:url(/content/static/icons/buttonbg.gif)
> }
> .ButtonStyle
> {
> margin: 0px; padding: 2px 4px 2px 4px;
> border: 0px;
> background-color: transparent;
> font: 12px Tahoma, Helvetica, sans-serif;
> text-align: center;
> vertical-align: middle;
> cursor:pointer;
> }
>
>
>
> <afh:cellFormat styleClass="ButtonCell">
> <af:commandButton text="#{webStrings.OK}"
> action="#{actions.createFolder}"
> styleClass="ButtonStyle"/>
> </afh:cellFormat>
>
>
>
> Adam Winer wrote:
>
> > Oh, that...
> >
> > That opens up a new topic: what the heck should we do about
> > Trinidad button skinning?
> >
> > As a little background: ADF Faces had a large image-generation
> > subsystem code-named "Tecate" that took text, metadata, and
> > other images, and composited them into single images. This
> > let us have fancy-looking buttons containing, for example,
> > translatable text. Instead of trying to get thousands of button
> > images translated (which would have been a nightmare), developers
> > just got text translated as normal and Tecate did the heavy lifting
> > at runtime.
> >
> > It was used for more than buttons - tabs and "global buttons" (now
> > hint="buttons" on navigationPane) also went through this system.
> >
> > At a certain point, we decided this was just a bad idea, and that a
> > better approach was a straightforward HTML and CSS skinning
> > approach. So, most of the code moved away from Tecate.
> >
> > As of Trinidad, though, buttons were still left on it. And, as a
> result,
> > we have the large org.apache.myfaces.trinidadinternal.image package -
> > and all of the code in there - just for one simple feature.
> >
> > I'd really like to come up with a simpler button skinning strategy,
> > and kill the "image" package altogether. The simplest possible
> > strategy is just HTML along the lines of:
> >
> > <button class="af_commandButton>...</button>
> >
> > -- Adam
> >
> >
> >
> > On 8/17/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> >
> >>
> >> Unless those exist and are not documented it would not work because
the
> >> button image is composed of 8 part, one background and one text all
> >> merged
> >> together in a single image. So using CSS :hover and :active on the 9
> >> selectors would not work. Furthermore if I remember well :hover and
> >> :active works only for links under IE.
> >>
> >> Maybe those are managed by the skin already but I never figured it
out
> >> though. Jeanne, can you confirm please?
> >>
> >>
> >> ¬Simon
> >>
> >>
> >>
> >>
> >>
> >> "Adam Winer" <aw...@gmail.com>
> >> 2006-08-16 16:47
> >> Please respond to adffaces-dev
> >>
> >> To: adffaces-dev@incubator.apache.org
> >> cc:
> >> Subject: Re: [Proposal] Skin hooks for mouseOver and
> >> onPress
> >>
> >>
> >> Isn't this just :hover and :active?
> >>
> >> -- Adam
> >>
> >>
> >> On 8/16/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> >> > Hello all,
> >> >
> >> > I just had a flashback from my ADF Faces project. In that project
we
> >> > wanted to use a different image on mouse over event. In the end we
> had
> >> to
> >> > use commandLink with an image and some JavaScript events instead.
> >> So my
> >> > suggestion about button would be to add skin state hooks for
> mouseOver
> >> and
> >> > mouseDown occuring on buttons to improve their L&F and thus user
> >> > experience.
> >> >
> >> > ¬Simon
> >> >
> >>
> >>
> >>
> >
>
>
>
>
Re: Button skinning (was Re: [Proposal] Skin hooks for mouseOver and onPress)
Posted by Adam Winer <aw...@gmail.com>.
On 8/17/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
>
> I just tested those style classes, they're prety nice.However, I think the
> results are better with simply the following
>
> .ButtonCellIE
> {
> margin: 0px;
> padding: 0px;
> background-image: url(background.jpg);
> }
>
> .ButtonStyleIE
> {
> background-color: transparent;
> }
>
> .ButtonCellFirefox
> {
> margin: 0px;
> padding: 0px;
> }
>
> .ButtonStyleFirefox
> {
> background-image: url(background.jpg);
> }
>
>
> It seems that Firefox supports button background-images natively, it works
> even without the cell and the result is better oveall. Sadly div does not
> work well.
In FireFox? Hrm, I've used background-images on divs in Firefox and IE,
and had it worked in both.
This solution also has its drawback since you cannot use round borders.
> For buttons it might not be a huge issue, but navigationPane might hurt,
> especially for tabs. So until we can provide users with an equal
> flexibility system for tabs I will be
>
> -1 on removing image package
> +1 on removing button dependancy toward image package.
>
If the button code doesn't depend on it, then it's a lot of code
that isn't used at all... it's in the Subversion repository, so anyone
so inclined could always resurrect it for a given purpose, but I'd
rather kill it until someone actually wants it.
-- Adam
¬ Simon
>
>
>
>
>
>
> Jeanne Waldman <je...@oracle.com>
> 2006-08-17 12:55
> Please respond to adffaces-dev
>
> To: adffaces-dev@incubator.apache.org
> cc:
> Subject: Re: Button skinning (was Re: [Proposal] Skin hooks
> for mouseOver and onPress)
>
>
> We had a customer that wanted to put background images on our buttons.
> He couldn't do this with our buttons unless they had a container
> (I haven't tested this in ages, but I remember that he was right), so what
> he did was wrap our command button in a afh:cellFormat and put a
> styleClass on both.
> The problem was that he couldn't style buttons that were rendered as a
> part
> of another component, so some of his buttons had a gradient background and
> some didn't.
>
> I recommend that we wrap our <button> html tag with
> a <div> or something so that the skinner can put background images on the
> buttons.
>
> The following is how he skinned the commandButton:
>
>
> .ButtonCell
> {
> margin: 0px; padding: 0px;
> border-top: 1px solid #afc6d7; border-left: 1px solid #afc6d7;
> border-bottom: 1px solid #666666; border-right: 1px solid #666666;
> background-repeat: repeat-x; background-position: bottom left;
> background-color: #ffffff;
> text-align: center;
> vertical-align: middle;
> background-image:url(/content/static/icons/buttonbg.gif)
> }
> .ButtonStyle
> {
> margin: 0px; padding: 2px 4px 2px 4px;
> border: 0px;
> background-color: transparent;
> font: 12px Tahoma, Helvetica, sans-serif;
> text-align: center;
> vertical-align: middle;
> cursor:pointer;
> }
>
>
>
> <afh:cellFormat styleClass="ButtonCell">
> <af:commandButton text="#{webStrings.OK}"
> action="#{actions.createFolder}"
> styleClass="ButtonStyle"/>
> </afh:cellFormat>
>
>
>
> Adam Winer wrote:
>
> > Oh, that...
> >
> > That opens up a new topic: what the heck should we do about
> > Trinidad button skinning?
> >
> > As a little background: ADF Faces had a large image-generation
> > subsystem code-named "Tecate" that took text, metadata, and
> > other images, and composited them into single images. This
> > let us have fancy-looking buttons containing, for example,
> > translatable text. Instead of trying to get thousands of button
> > images translated (which would have been a nightmare), developers
> > just got text translated as normal and Tecate did the heavy lifting
> > at runtime.
> >
> > It was used for more than buttons - tabs and "global buttons" (now
> > hint="buttons" on navigationPane) also went through this system.
> >
> > At a certain point, we decided this was just a bad idea, and that a
> > better approach was a straightforward HTML and CSS skinning
> > approach. So, most of the code moved away from Tecate.
> >
> > As of Trinidad, though, buttons were still left on it. And, as a
> result,
> > we have the large org.apache.myfaces.trinidadinternal.image package -
> > and all of the code in there - just for one simple feature.
> >
> > I'd really like to come up with a simpler button skinning strategy,
> > and kill the "image" package altogether. The simplest possible
> > strategy is just HTML along the lines of:
> >
> > <button class="af_commandButton>...</button>
> >
> > -- Adam
> >
> >
> >
> > On 8/17/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> >
> >>
> >> Unless those exist and are not documented it would not work because the
> >> button image is composed of 8 part, one background and one text all
> >> merged
> >> together in a single image. So using CSS :hover and :active on the 9
> >> selectors would not work. Furthermore if I remember well :hover and
> >> :active works only for links under IE.
> >>
> >> Maybe those are managed by the skin already but I never figured it out
> >> though. Jeanne, can you confirm please?
> >>
> >>
> >> ¬Simon
> >>
> >>
> >>
> >>
> >>
> >> "Adam Winer" <aw...@gmail.com>
> >> 2006-08-16 16:47
> >> Please respond to adffaces-dev
> >>
> >> To: adffaces-dev@incubator.apache.org
> >> cc:
> >> Subject: Re: [Proposal] Skin hooks for mouseOver and
> >> onPress
> >>
> >>
> >> Isn't this just :hover and :active?
> >>
> >> -- Adam
> >>
> >>
> >> On 8/16/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> >> > Hello all,
> >> >
> >> > I just had a flashback from my ADF Faces project. In that project we
> >> > wanted to use a different image on mouse over event. In the end we
> had
> >> to
> >> > use commandLink with an image and some JavaScript events instead.
> >> So my
> >> > suggestion about button would be to add skin state hooks for
> mouseOver
> >> and
> >> > mouseDown occuring on buttons to improve their L&F and thus user
> >> > experience.
> >> >
> >> > ¬Simon
> >> >
> >>
> >>
> >>
> >
>
>
>
>
Re: [Issue] inputNumberSpinbox: endless repeat
Posted by Si...@DMR.CA.
Hello Jeanne,
I found how to reproduce the issue.It happen if you send a mousedown event
without ever sending a mouseup. This can happen if you press the mouse
button while on increment then move our of the increment zone before
releasing the mouse button. I think a simple working fix would be to add a
_clearSpinbox(); call in mouseout JS event hook?
Regards,
¬ Simon
Jeanne Waldman <je...@oracle.com>
2006-08-17 18:26
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject: Re: [Issue] inputNumberSpinbox: endless repeat
I'm happy you found a bug. :) I'll try to investigate some, too. I use
Firefox mainly.
I wonder if it drops an event that tells it to stop. I wonder if there
should be some fallback that checks if the mouse is up every so often
Thanks,
Jeanne
Adam Winer wrote:
> I'm OK with a JIRA issue right away, just so it's known - in case
> you got called away or busy and never had a chance to investigate,
> we'd still have it tracked.
>
> -- Adam
>
>
>
> On 8/17/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
>
>> I know you'll hate me, but I found a bug in inputNumberSpinbox, but I
>> don't know how I triggered it (useful!). Anyway, it seems that under
>> some
>> circumstances _spinboxRepeat will keep going on forever. It happened
>> only
>> once so far, in Firefox. Once it happen there's no way to stop it.
>> Should
>> I open a JIRA issue for that right away or try to find the reproduction
>> case first?
>>
>> ¬ Simon
>>
>
Re: ADFFACES-49 inputText::content:required or inputText:required::content
Posted by Simon Lessard <si...@gmail.com>.
Idem.
On 8/24/06, Jeanne Waldman <je...@oracle.com> wrote:
>
> My opinion is that if you want the same pseudo-class to pass through
> when in one state and not when in the other state, then I would just not
> have it pass through in either case, and handle it yourself.
>
> - Jeanne
>
> Simon Lessard wrote:
>
> > Hello Pavitra,
> >
> > My solution would work with it as it is binary, the pseudo-class
> > either get
> > intercepted or pass through, independently of the enclosing element. For
> > :hover case, it would always go through for Firefox, except if the
> > component
> > said he wanted to intercept that pseudo-class and for IE it would
> > always get
> > intercepted, even on <a /> element since the JavaScript required to
> > emulate
> > a pseudo-class should always be the same, independently of the element.
> >
> > So in your case, it would not work. However, I wonder why you would
> > want to
> > intercept it in a case and not in the other as it only remove
> flexibility
> > for the end user imho. Can you explain the reason a bit more please?
> >
> >
> > Regards,
> >
> > ~ Simon
> >
> > On 8/23/06, Pavitra Subramaniam <pa...@oracle.com> wrote:
> >
> >>
> >> Hello Jeanne and Simon,
> >>
> >> There could be cases where intercepted states for a component or it's
> >> sub-part need to be considered together rather than individually. Or
> >> in some
> >> case it might be too early for even the renderer to provide a valid
> >> interceptor-state list at init time. The best time may be at
> >> rendering time.
> >>
> >> For instance, let's assume that the component sub-part "af|train::stop"
> >> can be in the following states :visited and :selected states.
> >>
> >> At runtime if the stop is selected, it may be rendered as a span and
> >> as an
> >> anchor, <a >, if it was visited before (and hence clickable). Both
> these
> >> elements may want to support the :hover pseudo-class.
> >>
> >> If I wanted the :hover to pass through if it's for selected stop (for
> >> the
> >> <span>) and intercept :hover if it's for a stop that is visited (link),
> >> would the proposed solution work?
> >>
> >>
> >> Thanks
> >> - Pavitra
> >>
> >> -----Original Message-----
> >> From: Simon Lessard [mailto:simon.lessard.3@gmail.com]
> >> Sent: Wednesday, August 23, 2006 6:28 AM
> >> To: adffaces-dev@incubator.apache.org
> >> Subject: Re: ADFFACES-49 inputText::content:required or
> >> inputText:required::content
> >>
> >> Hello Jeanne,
> >>
> >> Yes I'm aware that states can go on the component's sub-part, but are
> >> you
> >> suggesting that we extends the concept to be flexible enough to allow
> >> thecomponent to intercept a given state on the root element but not
> >> on the
> >> sub-part? e.g. inputText would intercept :disabled when placed on
> >> af|inputText but not on af|inputText::content? That's some complexity
> >> af|but
> >> it's doable I guess.
> >>
> >>
> >> Regards,
> >>
> >> ~Simon
> >>
> >> On 8/22/06, Jeanne Waldman <je...@oracle.com> wrote:
> >> >
> >> > I agree that only the renderers should know what states they want to
> >> > intercept. I was thinking we add this information in the renderer
> .xml
> >> > file and then when we build our classes, we can put this information
> >> > somewhere -- not sure where.
> >> >
> >> > I'm sure you realize this, but just in case... the states do not have
> >> > to go on the root dom element, they can go on sub-root elements, like
> >> > af|train::stop:disabled.
> >> >
> >> > Simon Lessard wrote:
> >> >
> >> > > Hmmm, I'm leaning toward the per component basis option more and
> >> more.
> >> > > However, I hate static lists and additional config files are not
> all
> >> > that
> >> > > great. I see a possibility though. Maybe it will work, but I did
> not
> >> > > explore that area much yet so I might say something stupid.
> >> > > Currently it seem to me that skins are linked to the renderkit. So,
> >> > > how feasible would it be to create a SkinRenderKitFactory that
> >> > > would, before giving away any renderer, would populate a
> >> > > Map<component, list<state>> be interrogating all renderers in the
> >> > > kit. That way, when StyleSheetRenderer would do its work, we would
> >> > > be sure that the list is populated. Also, with that solution, only
> >> > > the renderers would have to know what states they want to
> intercept.
> >> > > This also fix the synchronization issue, changing the kit or the
> >> > > renderer would automatically update the interception list. We would
> >> > > have to create a
> >> > new
> >> > > BaseRenderer in the API however. I see two additional methods
> needed
> >> > > for such renderers:
> >> > >
> >> > > public String getComponentName() // or I guess getRootStyleClass
> >> > > would work just as well public List<String> getInterceptedStates();
> >> > > // Returning the list of states to intercept.
> >> > >
> >> > >
> >> > > Makes sense?
> >> > >
> >> > > ~ Simon
> >> > >
> >> > > On 8/21/06, Jeanne Waldman <je...@oracle.com> wrote:
> >> > >
> >> > >>
> >> > >> More comments inline.
> >> > >> Which way are you leaning?
> >> > >>
> >> > >> - Jeanne
> >> > >>
> >> > >> Simon Lessard wrote:
> >> > >>
> >> > >> > Hello Jeanne,
> >> > >> >
> >> > >> > Thanks for the complete answer.
> >> > >> >
> >> > >> > On 8/21/06, Jeanne Waldman <jeanne.waldman@oracle.com > wrote:
> >> > >> >
> >> > >> >>
> >> > >> >> Hi Simon,
> >> > >> >> Thanks for the email.
> >> > >> >>
> >> > >> >> Simon_Lessard@DMR.CA wrote:
> >> > >> >>
> >> > >> >> >>We use both syntaxes, and they mean different things.
> >> > >> >> >>For example:
> >> > >> >> >>af|train::stop:disabled (when this train's stop is disabled,
> >> > >> >> >>af|then
> >> > >> >> style
> >> > >> >> >>the stop like this)
> >> > >> >> >>af|train:disabled::stop (when the entire train is disabled,
> >> > >> style all
> >> > >> >> >>the stops like this)
> >> > >> >> >>
> >> > >> >> >>
> >> > >> >> >
> >> > >> >> >Agreed.
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >>Let's say I have this: <span class="myText">Hello!</span> and
> >> > >> >> >>this
> >> > >> >> css:
> >> > >> >> >>.myText {color: black}
> >> > >> >> >>.myText:hover {color:red}
> >> > >> >> >>Does this work? (not in my tests)
> >> > >> >> >>
> >> > >> >> >>
> >> > >> >> >
> >> > >> >> >It works in Firefox, not IE, as usual. W3C specifies that
> >> > >> >> >:hover
> >> > >> should
> >> > >> >> >work with everything, but it's not like all browsers will
> >> > >> >> >support everything W3C says anytime soon. Maybe we should
> >> > >> >> >intercept all pseudo-classes, if it can be resolved on Java
> >> > >> >> >side (like
> >> > :disabled),
> >> > >> we
> >> > >> >> >resolve it there and it never pass through so we prevent all
> >> > >> >> >bad
> >> > >> >> support
> >> > >> >> >from the browser. For states that cannot be resolved in Java,
> >> > >> >> >we
> >> > >> could
> >> > >> >> ask
> >> > >> >> >the Agent if it supports the specified pseudo-class for the
> >> > >> generated
> >> > >> >> >element (link:hover works in IE, but not on anything else). If
> >> > >> >> >the
> >> > >> >> agent
> >> > >> >> >supports it, we let the class pass through to the generated
> CSS
> >> > >> >> file, if
> >> > >> >> >the agent does not, then we could add some JS code to
> >> emulate it.
> >> > >> >> >
> >> > >> >> >
> >> > >> >> We generate the css file before we render the components, so
> >> > >> >> when
> >> > you
> >> > >> >> say we should intercept all pseudo-classes and if it can be
> >> > >> resolved on
> >> > >> >> the Java side, we should resolve it. But how would we know at
> >> > >> >> this
> >> > >> point
> >> > >> >> where we are going to render the pseudo-class? that
> af|foo:hover
> >> > will
> >> > >> be
> >> > >> >> generated on a link? Maybe af|foo:hover is on a <span>, but
> >> > >> >> af|foo::step:hover is on the link. (we would know if we kept
> the
> >> > >> >> skinning-key -> pseudo-class to resolve map). Or do you mean
> >> > >> literally
> >> > >> >> that if we can resolve it on the Java side -- even if the
> >> > >> >> browser
> >> > can
> >> > >> as
> >> > >> >> well -- we go ahead and do that?
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> > I mean litterally that we make a list of pseudo-classes that we
> >> > >> > know we can always resolve during rendering, like :disabled, and
> >> > >> > always intercept it. In a sense it would be a way to cover
> >> > >> > browsers' lack of support for
> >> > those
> >> > >> > pseudo-classes.
> >> > >> >
> >> > >> > In the case of :hover, do we pass that through for IE or not?
> >> > >> > Let's
> >> > >> say
> >> > >> >
> >> > >> >> we don't pass it through for IE. Then we'll need some code that
> >> > >> >> gets :hover and says, oh, we are on IE, so don't pass this
> >> > >> >> through but instead do some onmouseover + css magic. This seems
> >> > >> >> like it could
> >> > get
> >> > >> >> messy fast.
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> > Fair point, the renderers would have to check if there's a
> >> > >> > selector
> >> > >> using
> >> > >> > :hover defined in the current skin and add some JS, it's messy
> >> > indeed.
> >> > >> >
> >> > >> >> The main problem I have the "per component" option is the
> >> > >> >> potential
> >> > >> >> >performance overhaul it represents as well as the increased
> >> > >> component
> >> > >> >> >development complexity (since you have to put more information
> >> > >> >> >in
> >> > >> the
> >> > >> >> >metadata).
> >> > >> >> >
> >> > >> >> >
> >> > >> >> I don't think of this as a performance hit, since this will
> >> > >> >> happen
> >> > at
> >> > >> >> the css generation time, not with every renderer. And we cache
> >> > >> >> the generated css file.
> >> > >> >> It would be like the map I have now in FileSystemStyleCache.
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> > Small question here. When is the CSS generated exactly? Is it at
> >> > >> > startup or at the first request for a given skin family? If it
> is
> >> > >> > during
> >> > startup,
> >> > >> > the
> >> > >> > performance hit is indeed a non issue.
> >> > >>
> >> > >> rendered in StyleSheetRenderer. We get it out of the cache if it
> is
> >> > >> there, otherwise we generate it.
> >> > >>
> >> > >> >
> >> > >> > However, we would need to keep the renderer and this map in
> sync.
> >> > >> For my
> >> > >> >
> >> > >> >> renderer 'foo', I know that I want to handle 'hover' myself, so
> >> > >> >> I
> >> > put
> >> > >> >> the hover -> p_AFHover in the map that will be consulted when
> we
> >> > >> >> generate the css file. af|foo:hover does not pass through. All
> >> > >> >> other :hover passes through. I don't think this is that
> >> > >> >> terrible. I like
> >> > >> this
> >> > >> >> better than the prefix, because if, down the line, we decide
> >> > >> >> that we
> >> > >> can
> >> > >> >> pass through the pseudo-class, the user's skin will not have to
> >> > >> change,
> >> > >> >> but our code will get simpler.
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> > Not that bad, but I kind of dislike hard coded lists as
> component
> >> > >> > developers won't be able to use the skinning feature without
> >> > >> > giving it to
> >> > >> Trinidad
> >> > >> > project since they will have to hack Trinidad's jar file to add
> >> > >> > their
> >> > >> own
> >> > >> > states to the map. If that way is chosen, I would rather use
> >> > >> > another configuration file or some faces-config meta-data
> >> > >> > entries. For now skin is not a public API, but I'm prety sure it
> >> > >> > will become one at some
> >> > >> point in
> >> > >> > time.
> >> > >>
> >> > >> We definitely need to get it out of FileSystemStyleCache. No doubt
> >> > about
> >> > >> it.
> >> > >>
> >> > >> >
> >> > >> >> The prefix is ok, but I find it a bit counter intuitive since
> >> > >> >> the user has
> >> > >> >> >to know which states will be handled by browser and which are
> >> > >> >> managed by
> >> > >> >> >Trinidad. I would prefer to hide that kind of low level
> >> > >> implementation
> >> > >> >> >details to skinners.
> >> > >> >> >
> >> > >> >> >
> >> > >> >> We would definitely document all the -tri- pseudo-classes per
> >> > >> skinning
> >> > >> >> key. For example:
> >> > >> >> af|inputText:-tri-required, af|inputText:-tri-read-only,
> >> > >> >> af|inputText:-tri-disabled. But for af|train::stop-link,
> >> > >> >> we'd document that they can use :hover.
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> > It works, but it's a bit ugly imho. Furthermore, as you pointed
> >> > >> > out,
> >> > >> such
> >> > >> > solution would force skin CSS changes if we beside to let any
> >> > >> > given
> >> > >> state
> >> > >> > pass through in the future.
> >> > >>
> >> > >> true.
> >> > >>
> >> > >> >
> >> > >> >> On a side note that could lead to a new post, what should we do
> >> > >> >> with
> >> > >> >> >icons? Currently the engine considers a selector an icon one
> if
> >> > >> >> >it
> >> > >> ends
> >> > >> >> >with -icon. This lead to some strange selectors sometimes like
> >> > >> >> >-icon-style-class simply to prevent the parser to interpret it
> >> > >> >> >as
> >> > an
> >> > >> >> icon.
> >> > >> >> >Maybe we should add something like :::icon, ::tri-icon or
> >> --icon?
> >> > >> That
> >> > >> >> way
> >> > >> >> >there will be no ambiguity left.
> >> > >> >> >
> >> > >> >> >
> >> > >> >> I don't have a problem with saying -icon-style when what you
> >> > >> >> mean is that you want to style the icon, and ending the key
> with
> >> > >> >> -icon
> >> > >> when it
> >> > >> >> means an icon.
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> > It's not that bad, true, but do we have a doc somewhere to
> >> > >> > document
> >> > >> this
> >> > >> > kind of skinning rules? If not, should I add a wiki entry for it
> >> > >> > even if the API is not public yet? Other things interesting I
> see
> >> > >> > are
> >> > >> FileSystemCache
> >> > >> > and the mandatory "af" namespace.
> >> > >>
> >> > >> We don't have a skinning document for Trinidad developers (as
> >> > >> opposed
> >> > to
> >> > >> application developers using Trinidad).
> >> > >> Starting a wiki would be great. I can populate it with some
> >> > >> information I have.
> >> > >>
> >> > >> Yeah, the namespace is purely to make it so that the skinner knows
> >> > there
> >> > >> are Trinidad keys.
> >> > >> We need to change these to tr for one thing. The code might be a
> >> > >> little bit hardcoded to use 'af', so that will need to change.
> >> > >> We don't honor the actual namespace in that you can't add
> >> > >> @namespace to the top of the css file and then be able to use
> >> > >> whatever prefix you want. That was very low priority when I was
> >> > >> doing the skinning, and I'm not so sure we'd want to do that
> >> > >> anyway, becuase what would we do, substitute the namespace for the
> >> > >> prefix? Then our css would be huge. :) Maybe some day the browsers
> >> > >> would work with the @namespace, and when that happens we can
> render
> >> > >> it out to our css.
> >> > >>
> >> > >> >
> >> > >> > - Jeanne
> >> > >> >
> >> > >> >>
> >> > >> >> >
> >> > >> >> >Regards
> >> > >> >> >
> >> > >> >> >� Simon
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >Jeanne Waldman <jeanne.waldman@oracle.com >
> >> > >> >> >2006-08-18 18:27
> >> > >> >> >Please respond to adffaces-dev
> >> > >> >> >
> >> > >> >> > To: adffaces-dev@incubator.apache.org
> >> > >> >> > cc:
> >> > >> >> > Subject: Re: ADFFACES-49
> >> > >> inputText::content:required or
> >> > >> >> >inputText:required::content
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >see inline for some random thoughts. :) I'm glad you brought
> >> > >> this up,
> >> > >> >> >because I need to come up with a solution soon for our
> internal
> >> > >> project
> >> > >> >> >that we are working on so that our developers can write their
> >> > >> renderers
> >> > >> >> >correctly.
> >> > >> >> >
> >> > >> >> >Simon_Lessard@DMR.CA wrote:
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >>Hello all,
> >> > >> >> >>
> >> > >> >> >>I raised that issue a while back, but now it's a bit more
> >> > important
> >> > >> >> since
> >> > >> >> >>
> >> > >> >> >>
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >>I'm trying to finalize ADFFACES-49 issue. What selector
> >> > >> >> >>synthax do
> >> > >> you
> >> > >> >> >>prefer for states:
> >> > >> >> >>1.1. <component>::<subPart>:<state> 1.2.
> >> > >> >> >><component>:<state>::<subPart>.
> >> > >> >> >>
> >> > >> >> >>
> >> > >> >> >>
> >> > >> >> >>
> >> > >> >> >We use both syntaxes, and they mean different things.
> >> > >> >> >
> >> > >> >> >1.1 means this: The subPart of the component is in this
> state.
> >> > >> >> >For example:
> >> > >> >> >af|train::stop:disabled (when this train's stop is disabled,
> >> > >> >> >af|then
> >> > >> style
> >> > >> >> >the stop like this)
> >> > >> >> >af|train:disabled::stop (when the entire train is disabled,
> >> > >> >> >af|style
> >> > >> all
> >> > >> >> >the stops like this)
> >> > >> >> >
> >> > >> >> >1.2 means this: The component is in this state, and this is
> the
> >> > >> >> subpart.
> >> > >> >> >For example:
> >> > >> >> >af|inputText:disabled::content (when the af:inputText
> >> > >> disabled="true",
> >> > >> >> >then style the content piece like this)
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >>I prefer the former and it's easier to implement. However, we
> >> > >> already
> >> > >> >> >>
> >> > >> >> >>
> >> > >> >> >have
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >>some :disabled that use the latter synthax.
> >> > >> >> >>
> >> > >> >> >>Secondly, there's also the issue raised by Jeanne, how should
> >> > >> >> >>we
> >> > >> >> manage
> >> > >> >> >>which states are intercepted and which should pass through
> and
> >> > >> >> >>be
> >> > >> >> copied
> >> > >> >> >>in the final CSS:
> >> > >> >> >>2.1. Use a component specific list, so that :disabled could
> >> > >> >> >>pass
> >> > >> >> through
> >> > >> >>
> >> > >> >> >>for some components but get intercepted for some others? If
> >> > >> >> >>that
> >> > >> >> solution
> >> > >> >> >>
> >> > >> >> >>
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >>is selected, how/where should we configure that list, in the
> >> > >> >> >>faces-config's metadata?
> >> > >> >> >>
> >> > >> >> >>
> >> > >> >> >>
> >> > >> >> >>
> >> > >> >> >I like this one the best because let's say I use :disabled and
> >> > >> >> >I intercept it and do some funky things with it. Then let's
> say
> >> > >> >> >I
> >> > >> decide
> >> > >> >> >that the css spec deals
> >> > >> >> >with :disabled perfectly fine, and I don't need to intercept
> >> it.
> >> > >> >> >Also, let's say :hover and :active work great on some dom
> >> > >> >> >elements,
> >> > >> but
> >> > >> >> >do they work for everything?
> >> > >> >> >Let's say I have this: <span class="myText">Hello!</span> and
> >> > >> >> >this
> >> > >> css:
> >> > >> >> >.myText {color: black}
> >> > >> >> >.myText:hover {color:red}
> >> > >> >> >Does this work? (not in my tests)
> >> > >> >> >
> >> > >> >> >But what if this represents a component. I might want them to
> >> > >> >> >be
> >> > >> >> able to
> >> > >> >> >specify .myText:hover and have it work even if the built-in
> >> > >> >> >browser support wasn't there.
> >> > >> >> >So I would want
> >> > >> >> >af|myComponent:hover to work.
> >> > >> >> >I'd render this
> >> > >> >> ><span class="af_myComponent p_AFHover">Hello!</span> when they
> >> > >> >> >are hovering over my span.
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >>2.2. Use a list of pseudo-classes passing through for all
> >> > >> components.
> >> > >> >> >>
> >> > >> >> >>
> >> > >> >> >Such
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >>list would have to be based on W3C, but as Jeanne observed,
> >> > >> >> >>such
> >> > >> list
> >> > >> >> >>would break our :disabled that we're intercepting currently
> >> > >> >> >>and
> >> > >> could
> >> > >> >> >>
> >> > >> >> >>
> >> > >> >> >lead
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >>to som.e problems if more pseudo-classes are added in future
> >> > >> >> version of
> >> > >> >> >>CSS.
> >> > >> >> >>
> >> > >> >> >>
> >> > >> >> >>
> >> > >> >> >>
> >> > >> >> >Yes, I'd have to change the name of :disabled. But so far that
> >> > >> >> >is
> >> > >> the
> >> > >> >> >only css valid pseudo-class that I use to date.
> >> > >> >> >We have others like :hover (see above... if we don't want this
> >> > >> >> >to
> >> > >> pass
> >> > >> >> >through, we'll need to change it to something else).
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >>2.3. Use a static list of pseudo-classes to intercept used by
> >> > >> >> >>all components? If so, where should we place it? This
> solution
> >> > probably
> >> > >> >> has
> >> > >> >> >>the same flaws as 2.2 if a new pseudo-classes i nthe CSS
> >> > >> specification
> >> > >> >> >>matches a name defined in the intercept list.
> >> > >> >> >>2.4. Use a prefix for intercepted pseudo-classes like the
> >> > >> >> >>-ora-
> >> > >> >> used for
> >> > >> >>
> >> > >> >> >>properties?
> >> > >> >> >>
> >> > >> >> >>
> >> > >> >> >>
> >> > >> >> >>
> >> > >> >> >I like this second best. If we did this, then I'd suggest that
> >> > >> >> >we
> >> > >> also
> >> > >> >> >prefix the pseudo-elements.
> >> > >> >> >The problem is, taking my :hover example, some components
> might
> >> > >> >> >be rendered such that the browser automatically works with
> >> > >> >> >:hover on the generated css, but others
> >> > >> don't,
> >> > >> >> >so those that don't have to have :-tri-hover ?
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >>My votes are:
> >> > >> >> >>+1 for 1.1
> >> > >> >> >>+1 for 2.2, but I would not place states resolvable during
> >> > >> >> rendering in
> >> > >> >> >>that list, so that disabled is still intercepted.
> >> > >> >> >>
> >> > >> >> >>
> >> > >> >> >>
> >> > >> >> >>
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >
> >> > >> >>
> >> > >> >>
> >> > >> >
> >> > >>
> >> > >>
> >> > >
> >> >
> >> >
> >>
> >>
> >>
>
>
RE: ADFFACES-49 inputText::content:required or
inputText:required::content
Posted by Pavitra Subramaniam <pa...@oracle.com>.
Ok. That makes sense.
- Pavitra
-----Original Message-----
From: Jeanne Waldman [mailto:jeanne.waldman@oracle.com]
Sent: Thursday, August 24, 2006 11:46 AM
To: adffaces-dev@incubator.apache.org
Cc: pavitra.subramaniam@oracle.com
Subject: Re: ADFFACES-49 inputText::content:required or inputText:required::content
My opinion is that if you want the same pseudo-class to pass through when in one state and not when in the other state, then I would just not have it pass through in either case, and handle it yourself.
- Jeanne
Simon Lessard wrote:
> Hello Pavitra,
>
> My solution would work with it as it is binary, the pseudo-class
> either get intercepted or pass through, independently of the enclosing
> element. For :hover case, it would always go through for Firefox,
> except if the component said he wanted to intercept that pseudo-class
> and for IE it would always get intercepted, even on <a /> element
> since the JavaScript required to emulate a pseudo-class should always
> be the same, independently of the element.
>
> So in your case, it would not work. However, I wonder why you would
> want to intercept it in a case and not in the other as it only remove
> flexibility for the end user imho. Can you explain the reason a bit
> more please?
>
>
> Regards,
>
> ~ Simon
>
> On 8/23/06, Pavitra Subramaniam <pa...@oracle.com> wrote:
>
>>
>> Hello Jeanne and Simon,
>>
>> There could be cases where intercepted states for a component or it's
>> sub-part need to be considered together rather than individually. Or
>> in some case it might be too early for even the renderer to provide a
>> valid interceptor-state list at init time. The best time may be at
>> rendering time.
>>
>> For instance, let's assume that the component sub-part "af|train::stop"
>> can be in the following states :visited and :selected states.
>>
>> At runtime if the stop is selected, it may be rendered as a span and
>> as an anchor, <a >, if it was visited before (and hence clickable).
>> Both these elements may want to support the :hover pseudo-class.
>>
>> If I wanted the :hover to pass through if it's for selected stop (for
>> the
>> <span>) and intercept :hover if it's for a stop that is visited
>> (link), would the proposed solution work?
>>
>>
>> Thanks
>> - Pavitra
>>
>> -----Original Message-----
>> From: Simon Lessard [mailto:simon.lessard.3@gmail.com]
>> Sent: Wednesday, August 23, 2006 6:28 AM
>> To: adffaces-dev@incubator.apache.org
>> Subject: Re: ADFFACES-49 inputText::content:required or
>> inputText:required::content
>>
>> Hello Jeanne,
>>
>> Yes I'm aware that states can go on the component's sub-part, but are
>> you suggesting that we extends the concept to be flexible enough to
>> allow thecomponent to intercept a given state on the root element but
>> not on the sub-part? e.g. inputText would intercept :disabled when
>> placed on
>> af|inputText but not on af|inputText::content? That's some complexity
>> af|but
>> it's doable I guess.
>>
>>
>> Regards,
>>
>> ~Simon
>>
>> On 8/22/06, Jeanne Waldman <je...@oracle.com> wrote:
>> >
>> > I agree that only the renderers should know what states they want
>> > to intercept. I was thinking we add this information in the
>> > renderer .xml file and then when we build our classes, we can put
>> > this information somewhere -- not sure where.
>> >
>> > I'm sure you realize this, but just in case... the states do not
>> > have to go on the root dom element, they can go on sub-root
>> > elements, like
>> > af|train::stop:disabled.
>> >
>> > Simon Lessard wrote:
>> >
>> > > Hmmm, I'm leaning toward the per component basis option more and
>> more.
>> > > However, I hate static lists and additional config files are not
>> > > all
>> > that
>> > > great. I see a possibility though. Maybe it will work, but I did
>> > > not explore that area much yet so I might say something stupid.
>> > > Currently it seem to me that skins are linked to the renderkit.
>> > > So, how feasible would it be to create a SkinRenderKitFactory
>> > > that would, before giving away any renderer, would populate a
>> > > Map<component, list<state>> be interrogating all renderers in the
>> > > kit. That way, when StyleSheetRenderer would do its work, we
>> > > would be sure that the list is populated. Also, with that
>> > > solution, only the renderers would have to know what states they want to intercept.
>> > > This also fix the synchronization issue, changing the kit or the
>> > > renderer would automatically update the interception list. We
>> > > would have to create a
>> > new
>> > > BaseRenderer in the API however. I see two additional methods
>> > > needed for such renderers:
>> > >
>> > > public String getComponentName() // or I guess getRootStyleClass
>> > > would work just as well public List<String>
>> > > getInterceptedStates(); // Returning the list of states to intercept.
>> > >
>> > >
>> > > Makes sense?
>> > >
>> > > ~ Simon
>> > >
>> > > On 8/21/06, Jeanne Waldman <je...@oracle.com> wrote:
>> > >
>> > >>
>> > >> More comments inline.
>> > >> Which way are you leaning?
>> > >>
>> > >> - Jeanne
>> > >>
>> > >> Simon Lessard wrote:
>> > >>
>> > >> > Hello Jeanne,
>> > >> >
>> > >> > Thanks for the complete answer.
>> > >> >
>> > >> > On 8/21/06, Jeanne Waldman <jeanne.waldman@oracle.com > wrote:
>> > >> >
>> > >> >>
>> > >> >> Hi Simon,
>> > >> >> Thanks for the email.
>> > >> >>
>> > >> >> Simon_Lessard@DMR.CA wrote:
>> > >> >>
>> > >> >> >>We use both syntaxes, and they mean different things.
>> > >> >> >>For example:
>> > >> >> >>af|train::stop:disabled (when this train's stop is
>> > >> >> >>af|disabled, then
>> > >> >> style
>> > >> >> >>the stop like this)
>> > >> >> >>af|train:disabled::stop (when the entire train is disabled,
>> > >> style all
>> > >> >> >>the stops like this)
>> > >> >> >>
>> > >> >> >>
>> > >> >> >
>> > >> >> >Agreed.
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >>Let's say I have this: <span class="myText">Hello!</span>
>> > >> >> >>and this
>> > >> >> css:
>> > >> >> >>.myText {color: black}
>> > >> >> >>.myText:hover {color:red}
>> > >> >> >>Does this work? (not in my tests)
>> > >> >> >>
>> > >> >> >>
>> > >> >> >
>> > >> >> >It works in Firefox, not IE, as usual. W3C specifies that
>> > >> >> >:hover
>> > >> should
>> > >> >> >work with everything, but it's not like all browsers will
>> > >> >> >support everything W3C says anytime soon. Maybe we should
>> > >> >> >intercept all pseudo-classes, if it can be resolved on Java
>> > >> >> >side (like
>> > :disabled),
>> > >> we
>> > >> >> >resolve it there and it never pass through so we prevent all
>> > >> >> >bad
>> > >> >> support
>> > >> >> >from the browser. For states that cannot be resolved in
>> > >> >> >Java, we
>> > >> could
>> > >> >> ask
>> > >> >> >the Agent if it supports the specified pseudo-class for the
>> > >> generated
>> > >> >> >element (link:hover works in IE, but not on anything else).
>> > >> >> >If the
>> > >> >> agent
>> > >> >> >supports it, we let the class pass through to the generated
>> > >> >> >CSS
>> > >> >> file, if
>> > >> >> >the agent does not, then we could add some JS code to
>> emulate it.
>> > >> >> >
>> > >> >> >
>> > >> >> We generate the css file before we render the components, so
>> > >> >> when
>> > you
>> > >> >> say we should intercept all pseudo-classes and if it can be
>> > >> resolved on
>> > >> >> the Java side, we should resolve it. But how would we know at
>> > >> >> this
>> > >> point
>> > >> >> where we are going to render the pseudo-class? that
>> > >> >> af|foo:hover
>> > will
>> > >> be
>> > >> >> generated on a link? Maybe af|foo:hover is on a <span>, but
>> > >> >> af|foo::step:hover is on the link. (we would know if we kept
>> > >> >> af|the
>> > >> >> skinning-key -> pseudo-class to resolve map). Or do you mean
>> > >> literally
>> > >> >> that if we can resolve it on the Java side -- even if the
>> > >> >> browser
>> > can
>> > >> as
>> > >> >> well -- we go ahead and do that?
>> > >> >
>> > >> >
>> > >> >
>> > >> > I mean litterally that we make a list of pseudo-classes that
>> > >> > we know we can always resolve during rendering, like
>> > >> > :disabled, and always intercept it. In a sense it would be a
>> > >> > way to cover browsers' lack of support for
>> > those
>> > >> > pseudo-classes.
>> > >> >
>> > >> > In the case of :hover, do we pass that through for IE or not?
>> > >> > Let's
>> > >> say
>> > >> >
>> > >> >> we don't pass it through for IE. Then we'll need some code
>> > >> >> that gets :hover and says, oh, we are on IE, so don't pass
>> > >> >> this through but instead do some onmouseover + css magic.
>> > >> >> This seems like it could
>> > get
>> > >> >> messy fast.
>> > >> >
>> > >> >
>> > >> >
>> > >> > Fair point, the renderers would have to check if there's a
>> > >> > selector
>> > >> using
>> > >> > :hover defined in the current skin and add some JS, it's messy
>> > indeed.
>> > >> >
>> > >> >> The main problem I have the "per component" option is the
>> > >> >> potential
>> > >> >> >performance overhaul it represents as well as the increased
>> > >> component
>> > >> >> >development complexity (since you have to put more
>> > >> >> >information in
>> > >> the
>> > >> >> >metadata).
>> > >> >> >
>> > >> >> >
>> > >> >> I don't think of this as a performance hit, since this will
>> > >> >> happen
>> > at
>> > >> >> the css generation time, not with every renderer. And we
>> > >> >> cache the generated css file.
>> > >> >> It would be like the map I have now in FileSystemStyleCache.
>> > >> >
>> > >> >
>> > >> >
>> > >> > Small question here. When is the CSS generated exactly? Is it
>> > >> > at startup or at the first request for a given skin family? If
>> > >> > it is during
>> > startup,
>> > >> > the
>> > >> > performance hit is indeed a non issue.
>> > >>
>> > >> rendered in StyleSheetRenderer. We get it out of the cache if it
>> > >> is there, otherwise we generate it.
>> > >>
>> > >> >
>> > >> > However, we would need to keep the renderer and this map in sync.
>> > >> For my
>> > >> >
>> > >> >> renderer 'foo', I know that I want to handle 'hover' myself,
>> > >> >> so I
>> > put
>> > >> >> the hover -> p_AFHover in the map that will be consulted when
>> > >> >> we generate the css file. af|foo:hover does not pass through.
>> > >> >> All other :hover passes through. I don't think this is that
>> > >> >> terrible. I like
>> > >> this
>> > >> >> better than the prefix, because if, down the line, we decide
>> > >> >> that we
>> > >> can
>> > >> >> pass through the pseudo-class, the user's skin will not have
>> > >> >> to
>> > >> change,
>> > >> >> but our code will get simpler.
>> > >> >
>> > >> >
>> > >> >
>> > >> > Not that bad, but I kind of dislike hard coded lists as
>> > >> > component developers won't be able to use the skinning feature
>> > >> > without giving it to
>> > >> Trinidad
>> > >> > project since they will have to hack Trinidad's jar file to
>> > >> > add their
>> > >> own
>> > >> > states to the map. If that way is chosen, I would rather use
>> > >> > another configuration file or some faces-config meta-data
>> > >> > entries. For now skin is not a public API, but I'm prety sure
>> > >> > it will become one at some
>> > >> point in
>> > >> > time.
>> > >>
>> > >> We definitely need to get it out of FileSystemStyleCache. No
>> > >> doubt
>> > about
>> > >> it.
>> > >>
>> > >> >
>> > >> >> The prefix is ok, but I find it a bit counter intuitive since
>> > >> >> the user has
>> > >> >> >to know which states will be handled by browser and which
>> > >> >> >are
>> > >> >> managed by
>> > >> >> >Trinidad. I would prefer to hide that kind of low level
>> > >> implementation
>> > >> >> >details to skinners.
>> > >> >> >
>> > >> >> >
>> > >> >> We would definitely document all the -tri- pseudo-classes per
>> > >> skinning
>> > >> >> key. For example:
>> > >> >> af|inputText:-tri-required, af|inputText:-tri-read-only,
>> > >> >> af|inputText:-tri-disabled. But for af|train::stop-link,
>> > >> >> we'd document that they can use :hover.
>> > >> >
>> > >> >
>> > >> >
>> > >> > It works, but it's a bit ugly imho. Furthermore, as you
>> > >> > pointed out,
>> > >> such
>> > >> > solution would force skin CSS changes if we beside to let any
>> > >> > given
>> > >> state
>> > >> > pass through in the future.
>> > >>
>> > >> true.
>> > >>
>> > >> >
>> > >> >> On a side note that could lead to a new post, what should we
>> > >> >> do with
>> > >> >> >icons? Currently the engine considers a selector an icon one
>> > >> >> >if it
>> > >> ends
>> > >> >> >with -icon. This lead to some strange selectors sometimes
>> > >> >> >like -icon-style-class simply to prevent the parser to
>> > >> >> >interpret it as
>> > an
>> > >> >> icon.
>> > >> >> >Maybe we should add something like :::icon, ::tri-icon or
>> --icon?
>> > >> That
>> > >> >> way
>> > >> >> >there will be no ambiguity left.
>> > >> >> >
>> > >> >> >
>> > >> >> I don't have a problem with saying -icon-style when what you
>> > >> >> mean is that you want to style the icon, and ending the key
>> > >> >> with -icon
>> > >> when it
>> > >> >> means an icon.
>> > >> >
>> > >> >
>> > >> >
>> > >> > It's not that bad, true, but do we have a doc somewhere to
>> > >> > document
>> > >> this
>> > >> > kind of skinning rules? If not, should I add a wiki entry for
>> > >> > it even if the API is not public yet? Other things interesting
>> > >> > I see are
>> > >> FileSystemCache
>> > >> > and the mandatory "af" namespace.
>> > >>
>> > >> We don't have a skinning document for Trinidad developers (as
>> > >> opposed
>> > to
>> > >> application developers using Trinidad).
>> > >> Starting a wiki would be great. I can populate it with some
>> > >> information I have.
>> > >>
>> > >> Yeah, the namespace is purely to make it so that the skinner
>> > >> knows
>> > there
>> > >> are Trinidad keys.
>> > >> We need to change these to tr for one thing. The code might be a
>> > >> little bit hardcoded to use 'af', so that will need to change.
>> > >> We don't honor the actual namespace in that you can't add
>> > >> @namespace to the top of the css file and then be able to use
>> > >> whatever prefix you want. That was very low priority when I was
>> > >> doing the skinning, and I'm not so sure we'd want to do that
>> > >> anyway, becuase what would we do, substitute the namespace for
>> > >> the prefix? Then our css would be huge. :) Maybe some day the
>> > >> browsers would work with the @namespace, and when that happens
>> > >> we can render it out to our css.
>> > >>
>> > >> >
>> > >> > - Jeanne
>> > >> >
>> > >> >>
>> > >> >> >
>> > >> >> >Regards
>> > >> >> >
>> > >> >> > Simon
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >Jeanne Waldman <jeanne.waldman@oracle.com >
>> > >> >> >2006-08-18 18:27
>> > >> >> >Please respond to adffaces-dev
>> > >> >> >
>> > >> >> > To: adffaces-dev@incubator.apache.org
>> > >> >> > cc:
>> > >> >> > Subject: Re: ADFFACES-49
>> > >> inputText::content:required or
>> > >> >> >inputText:required::content
>> > >> >> >
>> > >> >> >
>> > >> >> >see inline for some random thoughts. :) I'm glad you
>> > >> >> >brought
>> > >> this up,
>> > >> >> >because I need to come up with a solution soon for our
>> > >> >> >internal
>> > >> project
>> > >> >> >that we are working on so that our developers can write
>> > >> >> >their
>> > >> renderers
>> > >> >> >correctly.
>> > >> >> >
>> > >> >> >Simon_Lessard@DMR.CA wrote:
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >>Hello all,
>> > >> >> >>
>> > >> >> >>I raised that issue a while back, but now it's a bit more
>> > important
>> > >> >> since
>> > >> >> >>
>> > >> >> >>
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >>I'm trying to finalize ADFFACES-49 issue. What selector
>> > >> >> >>synthax do
>> > >> you
>> > >> >> >>prefer for states:
>> > >> >> >>1.1. <component>::<subPart>:<state> 1.2.
>> > >> >> >><component>:<state>::<subPart>.
>> > >> >> >>
>> > >> >> >>
>> > >> >> >>
>> > >> >> >>
>> > >> >> >We use both syntaxes, and they mean different things.
>> > >> >> >
>> > >> >> >1.1 means this: The subPart of the component is in this state.
>> > >> >> >For example:
>> > >> >> >af|train::stop:disabled (when this train's stop is disabled,
>> > >> >> >af|then
>> > >> style
>> > >> >> >the stop like this)
>> > >> >> >af|train:disabled::stop (when the entire train is disabled,
>> > >> >> >af|style
>> > >> all
>> > >> >> >the stops like this)
>> > >> >> >
>> > >> >> >1.2 means this: The component is in this state, and this is
>> > >> >> >the
>> > >> >> subpart.
>> > >> >> >For example:
>> > >> >> >af|inputText:disabled::content (when the af:inputText
>> > >> disabled="true",
>> > >> >> >then style the content piece like this)
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >>I prefer the former and it's easier to implement. However,
>> > >> >> >>we
>> > >> already
>> > >> >> >>
>> > >> >> >>
>> > >> >> >have
>> > >> >> >
>> > >> >> >
>> > >> >> >>some :disabled that use the latter synthax.
>> > >> >> >>
>> > >> >> >>Secondly, there's also the issue raised by Jeanne, how
>> > >> >> >>should we
>> > >> >> manage
>> > >> >> >>which states are intercepted and which should pass through
>> > >> >> >>and be
>> > >> >> copied
>> > >> >> >>in the final CSS:
>> > >> >> >>2.1. Use a component specific list, so that :disabled could
>> > >> >> >>pass
>> > >> >> through
>> > >> >>
>> > >> >> >>for some components but get intercepted for some others? If
>> > >> >> >>that
>> > >> >> solution
>> > >> >> >>
>> > >> >> >>
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >>is selected, how/where should we configure that list, in
>> > >> >> >>the faces-config's metadata?
>> > >> >> >>
>> > >> >> >>
>> > >> >> >>
>> > >> >> >>
>> > >> >> >I like this one the best because let's say I use :disabled
>> > >> >> >and I intercept it and do some funky things with it. Then
>> > >> >> >let's say I
>> > >> decide
>> > >> >> >that the css spec deals
>> > >> >> >with :disabled perfectly fine, and I don't need to intercept
>> it.
>> > >> >> >Also, let's say :hover and :active work great on some dom
>> > >> >> >elements,
>> > >> but
>> > >> >> >do they work for everything?
>> > >> >> >Let's say I have this: <span class="myText">Hello!</span>
>> > >> >> >and this
>> > >> css:
>> > >> >> >.myText {color: black}
>> > >> >> >.myText:hover {color:red}
>> > >> >> >Does this work? (not in my tests)
>> > >> >> >
>> > >> >> >But what if this represents a component. I might want them
>> > >> >> >to be
>> > >> >> able to
>> > >> >> >specify .myText:hover and have it work even if the built-in
>> > >> >> >browser support wasn't there.
>> > >> >> >So I would want
>> > >> >> >af|myComponent:hover to work.
>> > >> >> >I'd render this
>> > >> >> ><span class="af_myComponent p_AFHover">Hello!</span> when
>> > >> >> >they are hovering over my span.
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >>2.2. Use a list of pseudo-classes passing through for all
>> > >> components.
>> > >> >> >>
>> > >> >> >>
>> > >> >> >Such
>> > >> >> >
>> > >> >> >
>> > >> >> >>list would have to be based on W3C, but as Jeanne observed,
>> > >> >> >>such
>> > >> list
>> > >> >> >>would break our :disabled that we're intercepting currently
>> > >> >> >>and
>> > >> could
>> > >> >> >>
>> > >> >> >>
>> > >> >> >lead
>> > >> >> >
>> > >> >> >
>> > >> >> >>to som.e problems if more pseudo-classes are added in
>> > >> >> >>future
>> > >> >> version of
>> > >> >> >>CSS.
>> > >> >> >>
>> > >> >> >>
>> > >> >> >>
>> > >> >> >>
>> > >> >> >Yes, I'd have to change the name of :disabled. But so far
>> > >> >> >that is
>> > >> the
>> > >> >> >only css valid pseudo-class that I use to date.
>> > >> >> >We have others like :hover (see above... if we don't want
>> > >> >> >this to
>> > >> pass
>> > >> >> >through, we'll need to change it to something else).
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >>2.3. Use a static list of pseudo-classes to intercept used
>> > >> >> >>by all components? If so, where should we place it? This
>> > >> >> >>solution
>> > probably
>> > >> >> has
>> > >> >> >>the same flaws as 2.2 if a new pseudo-classes i nthe CSS
>> > >> specification
>> > >> >> >>matches a name defined in the intercept list.
>> > >> >> >>2.4. Use a prefix for intercepted pseudo-classes like the
>> > >> >> >>-ora-
>> > >> >> used for
>> > >> >>
>> > >> >> >>properties?
>> > >> >> >>
>> > >> >> >>
>> > >> >> >>
>> > >> >> >>
>> > >> >> >I like this second best. If we did this, then I'd suggest
>> > >> >> >that we
>> > >> also
>> > >> >> >prefix the pseudo-elements.
>> > >> >> >The problem is, taking my :hover example, some components
>> > >> >> >might be rendered such that the browser automatically works
>> > >> >> >with :hover on the generated css, but others
>> > >> don't,
>> > >> >> >so those that don't have to have :-tri-hover ?
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >>My votes are:
>> > >> >> >>+1 for 1.1
>> > >> >> >>+1 for 2.2, but I would not place states resolvable during
>> > >> >> rendering in
>> > >> >> >>that list, so that disabled is still intercepted.
>> > >> >> >>
>> > >> >> >>
>> > >> >> >>
>> > >> >> >>
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >>
>> > >> >>
>> > >> >
>> > >>
>> > >>
>> > >
>> >
>> >
>>
>>
>>
Re: ADFFACES-49 inputText::content:required or inputText:required::content
Posted by Jeanne Waldman <je...@oracle.com>.
My opinion is that if you want the same pseudo-class to pass through
when in one state and not when in the other state, then I would just not
have it pass through in either case, and handle it yourself.
- Jeanne
Simon Lessard wrote:
> Hello Pavitra,
>
> My solution would work with it as it is binary, the pseudo-class
> either get
> intercepted or pass through, independently of the enclosing element. For
> :hover case, it would always go through for Firefox, except if the
> component
> said he wanted to intercept that pseudo-class and for IE it would
> always get
> intercepted, even on <a /> element since the JavaScript required to
> emulate
> a pseudo-class should always be the same, independently of the element.
>
> So in your case, it would not work. However, I wonder why you would
> want to
> intercept it in a case and not in the other as it only remove flexibility
> for the end user imho. Can you explain the reason a bit more please?
>
>
> Regards,
>
> ~ Simon
>
> On 8/23/06, Pavitra Subramaniam <pa...@oracle.com> wrote:
>
>>
>> Hello Jeanne and Simon,
>>
>> There could be cases where intercepted states for a component or it's
>> sub-part need to be considered together rather than individually. Or
>> in some
>> case it might be too early for even the renderer to provide a valid
>> interceptor-state list at init time. The best time may be at
>> rendering time.
>>
>> For instance, let's assume that the component sub-part "af|train::stop"
>> can be in the following states :visited and :selected states.
>>
>> At runtime if the stop is selected, it may be rendered as a span and
>> as an
>> anchor, <a >, if it was visited before (and hence clickable). Both these
>> elements may want to support the :hover pseudo-class.
>>
>> If I wanted the :hover to pass through if it's for selected stop (for
>> the
>> <span>) and intercept :hover if it's for a stop that is visited (link),
>> would the proposed solution work?
>>
>>
>> Thanks
>> - Pavitra
>>
>> -----Original Message-----
>> From: Simon Lessard [mailto:simon.lessard.3@gmail.com]
>> Sent: Wednesday, August 23, 2006 6:28 AM
>> To: adffaces-dev@incubator.apache.org
>> Subject: Re: ADFFACES-49 inputText::content:required or
>> inputText:required::content
>>
>> Hello Jeanne,
>>
>> Yes I'm aware that states can go on the component's sub-part, but are
>> you
>> suggesting that we extends the concept to be flexible enough to allow
>> thecomponent to intercept a given state on the root element but not
>> on the
>> sub-part? e.g. inputText would intercept :disabled when placed on
>> af|inputText but not on af|inputText::content? That's some complexity
>> af|but
>> it's doable I guess.
>>
>>
>> Regards,
>>
>> ~Simon
>>
>> On 8/22/06, Jeanne Waldman <je...@oracle.com> wrote:
>> >
>> > I agree that only the renderers should know what states they want to
>> > intercept. I was thinking we add this information in the renderer .xml
>> > file and then when we build our classes, we can put this information
>> > somewhere -- not sure where.
>> >
>> > I'm sure you realize this, but just in case... the states do not have
>> > to go on the root dom element, they can go on sub-root elements, like
>> > af|train::stop:disabled.
>> >
>> > Simon Lessard wrote:
>> >
>> > > Hmmm, I'm leaning toward the per component basis option more and
>> more.
>> > > However, I hate static lists and additional config files are not all
>> > that
>> > > great. I see a possibility though. Maybe it will work, but I did not
>> > > explore that area much yet so I might say something stupid.
>> > > Currently it seem to me that skins are linked to the renderkit. So,
>> > > how feasible would it be to create a SkinRenderKitFactory that
>> > > would, before giving away any renderer, would populate a
>> > > Map<component, list<state>> be interrogating all renderers in the
>> > > kit. That way, when StyleSheetRenderer would do its work, we would
>> > > be sure that the list is populated. Also, with that solution, only
>> > > the renderers would have to know what states they want to intercept.
>> > > This also fix the synchronization issue, changing the kit or the
>> > > renderer would automatically update the interception list. We would
>> > > have to create a
>> > new
>> > > BaseRenderer in the API however. I see two additional methods needed
>> > > for such renderers:
>> > >
>> > > public String getComponentName() // or I guess getRootStyleClass
>> > > would work just as well public List<String> getInterceptedStates();
>> > > // Returning the list of states to intercept.
>> > >
>> > >
>> > > Makes sense?
>> > >
>> > > ~ Simon
>> > >
>> > > On 8/21/06, Jeanne Waldman <je...@oracle.com> wrote:
>> > >
>> > >>
>> > >> More comments inline.
>> > >> Which way are you leaning?
>> > >>
>> > >> - Jeanne
>> > >>
>> > >> Simon Lessard wrote:
>> > >>
>> > >> > Hello Jeanne,
>> > >> >
>> > >> > Thanks for the complete answer.
>> > >> >
>> > >> > On 8/21/06, Jeanne Waldman <jeanne.waldman@oracle.com > wrote:
>> > >> >
>> > >> >>
>> > >> >> Hi Simon,
>> > >> >> Thanks for the email.
>> > >> >>
>> > >> >> Simon_Lessard@DMR.CA wrote:
>> > >> >>
>> > >> >> >>We use both syntaxes, and they mean different things.
>> > >> >> >>For example:
>> > >> >> >>af|train::stop:disabled (when this train's stop is disabled,
>> > >> >> >>af|then
>> > >> >> style
>> > >> >> >>the stop like this)
>> > >> >> >>af|train:disabled::stop (when the entire train is disabled,
>> > >> style all
>> > >> >> >>the stops like this)
>> > >> >> >>
>> > >> >> >>
>> > >> >> >
>> > >> >> >Agreed.
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >>Let's say I have this: <span class="myText">Hello!</span> and
>> > >> >> >>this
>> > >> >> css:
>> > >> >> >>.myText {color: black}
>> > >> >> >>.myText:hover {color:red}
>> > >> >> >>Does this work? (not in my tests)
>> > >> >> >>
>> > >> >> >>
>> > >> >> >
>> > >> >> >It works in Firefox, not IE, as usual. W3C specifies that
>> > >> >> >:hover
>> > >> should
>> > >> >> >work with everything, but it's not like all browsers will
>> > >> >> >support everything W3C says anytime soon. Maybe we should
>> > >> >> >intercept all pseudo-classes, if it can be resolved on Java
>> > >> >> >side (like
>> > :disabled),
>> > >> we
>> > >> >> >resolve it there and it never pass through so we prevent all
>> > >> >> >bad
>> > >> >> support
>> > >> >> >from the browser. For states that cannot be resolved in Java,
>> > >> >> >we
>> > >> could
>> > >> >> ask
>> > >> >> >the Agent if it supports the specified pseudo-class for the
>> > >> generated
>> > >> >> >element (link:hover works in IE, but not on anything else). If
>> > >> >> >the
>> > >> >> agent
>> > >> >> >supports it, we let the class pass through to the generated CSS
>> > >> >> file, if
>> > >> >> >the agent does not, then we could add some JS code to
>> emulate it.
>> > >> >> >
>> > >> >> >
>> > >> >> We generate the css file before we render the components, so
>> > >> >> when
>> > you
>> > >> >> say we should intercept all pseudo-classes and if it can be
>> > >> resolved on
>> > >> >> the Java side, we should resolve it. But how would we know at
>> > >> >> this
>> > >> point
>> > >> >> where we are going to render the pseudo-class? that af|foo:hover
>> > will
>> > >> be
>> > >> >> generated on a link? Maybe af|foo:hover is on a <span>, but
>> > >> >> af|foo::step:hover is on the link. (we would know if we kept the
>> > >> >> skinning-key -> pseudo-class to resolve map). Or do you mean
>> > >> literally
>> > >> >> that if we can resolve it on the Java side -- even if the
>> > >> >> browser
>> > can
>> > >> as
>> > >> >> well -- we go ahead and do that?
>> > >> >
>> > >> >
>> > >> >
>> > >> > I mean litterally that we make a list of pseudo-classes that we
>> > >> > know we can always resolve during rendering, like :disabled, and
>> > >> > always intercept it. In a sense it would be a way to cover
>> > >> > browsers' lack of support for
>> > those
>> > >> > pseudo-classes.
>> > >> >
>> > >> > In the case of :hover, do we pass that through for IE or not?
>> > >> > Let's
>> > >> say
>> > >> >
>> > >> >> we don't pass it through for IE. Then we'll need some code that
>> > >> >> gets :hover and says, oh, we are on IE, so don't pass this
>> > >> >> through but instead do some onmouseover + css magic. This seems
>> > >> >> like it could
>> > get
>> > >> >> messy fast.
>> > >> >
>> > >> >
>> > >> >
>> > >> > Fair point, the renderers would have to check if there's a
>> > >> > selector
>> > >> using
>> > >> > :hover defined in the current skin and add some JS, it's messy
>> > indeed.
>> > >> >
>> > >> >> The main problem I have the "per component" option is the
>> > >> >> potential
>> > >> >> >performance overhaul it represents as well as the increased
>> > >> component
>> > >> >> >development complexity (since you have to put more information
>> > >> >> >in
>> > >> the
>> > >> >> >metadata).
>> > >> >> >
>> > >> >> >
>> > >> >> I don't think of this as a performance hit, since this will
>> > >> >> happen
>> > at
>> > >> >> the css generation time, not with every renderer. And we cache
>> > >> >> the generated css file.
>> > >> >> It would be like the map I have now in FileSystemStyleCache.
>> > >> >
>> > >> >
>> > >> >
>> > >> > Small question here. When is the CSS generated exactly? Is it at
>> > >> > startup or at the first request for a given skin family? If it is
>> > >> > during
>> > startup,
>> > >> > the
>> > >> > performance hit is indeed a non issue.
>> > >>
>> > >> rendered in StyleSheetRenderer. We get it out of the cache if it is
>> > >> there, otherwise we generate it.
>> > >>
>> > >> >
>> > >> > However, we would need to keep the renderer and this map in sync.
>> > >> For my
>> > >> >
>> > >> >> renderer 'foo', I know that I want to handle 'hover' myself, so
>> > >> >> I
>> > put
>> > >> >> the hover -> p_AFHover in the map that will be consulted when we
>> > >> >> generate the css file. af|foo:hover does not pass through. All
>> > >> >> other :hover passes through. I don't think this is that
>> > >> >> terrible. I like
>> > >> this
>> > >> >> better than the prefix, because if, down the line, we decide
>> > >> >> that we
>> > >> can
>> > >> >> pass through the pseudo-class, the user's skin will not have to
>> > >> change,
>> > >> >> but our code will get simpler.
>> > >> >
>> > >> >
>> > >> >
>> > >> > Not that bad, but I kind of dislike hard coded lists as component
>> > >> > developers won't be able to use the skinning feature without
>> > >> > giving it to
>> > >> Trinidad
>> > >> > project since they will have to hack Trinidad's jar file to add
>> > >> > their
>> > >> own
>> > >> > states to the map. If that way is chosen, I would rather use
>> > >> > another configuration file or some faces-config meta-data
>> > >> > entries. For now skin is not a public API, but I'm prety sure it
>> > >> > will become one at some
>> > >> point in
>> > >> > time.
>> > >>
>> > >> We definitely need to get it out of FileSystemStyleCache. No doubt
>> > about
>> > >> it.
>> > >>
>> > >> >
>> > >> >> The prefix is ok, but I find it a bit counter intuitive since
>> > >> >> the user has
>> > >> >> >to know which states will be handled by browser and which are
>> > >> >> managed by
>> > >> >> >Trinidad. I would prefer to hide that kind of low level
>> > >> implementation
>> > >> >> >details to skinners.
>> > >> >> >
>> > >> >> >
>> > >> >> We would definitely document all the -tri- pseudo-classes per
>> > >> skinning
>> > >> >> key. For example:
>> > >> >> af|inputText:-tri-required, af|inputText:-tri-read-only,
>> > >> >> af|inputText:-tri-disabled. But for af|train::stop-link,
>> > >> >> we'd document that they can use :hover.
>> > >> >
>> > >> >
>> > >> >
>> > >> > It works, but it's a bit ugly imho. Furthermore, as you pointed
>> > >> > out,
>> > >> such
>> > >> > solution would force skin CSS changes if we beside to let any
>> > >> > given
>> > >> state
>> > >> > pass through in the future.
>> > >>
>> > >> true.
>> > >>
>> > >> >
>> > >> >> On a side note that could lead to a new post, what should we do
>> > >> >> with
>> > >> >> >icons? Currently the engine considers a selector an icon one if
>> > >> >> >it
>> > >> ends
>> > >> >> >with -icon. This lead to some strange selectors sometimes like
>> > >> >> >-icon-style-class simply to prevent the parser to interpret it
>> > >> >> >as
>> > an
>> > >> >> icon.
>> > >> >> >Maybe we should add something like :::icon, ::tri-icon or
>> --icon?
>> > >> That
>> > >> >> way
>> > >> >> >there will be no ambiguity left.
>> > >> >> >
>> > >> >> >
>> > >> >> I don't have a problem with saying -icon-style when what you
>> > >> >> mean is that you want to style the icon, and ending the key with
>> > >> >> -icon
>> > >> when it
>> > >> >> means an icon.
>> > >> >
>> > >> >
>> > >> >
>> > >> > It's not that bad, true, but do we have a doc somewhere to
>> > >> > document
>> > >> this
>> > >> > kind of skinning rules? If not, should I add a wiki entry for it
>> > >> > even if the API is not public yet? Other things interesting I see
>> > >> > are
>> > >> FileSystemCache
>> > >> > and the mandatory "af" namespace.
>> > >>
>> > >> We don't have a skinning document for Trinidad developers (as
>> > >> opposed
>> > to
>> > >> application developers using Trinidad).
>> > >> Starting a wiki would be great. I can populate it with some
>> > >> information I have.
>> > >>
>> > >> Yeah, the namespace is purely to make it so that the skinner knows
>> > there
>> > >> are Trinidad keys.
>> > >> We need to change these to tr for one thing. The code might be a
>> > >> little bit hardcoded to use 'af', so that will need to change.
>> > >> We don't honor the actual namespace in that you can't add
>> > >> @namespace to the top of the css file and then be able to use
>> > >> whatever prefix you want. That was very low priority when I was
>> > >> doing the skinning, and I'm not so sure we'd want to do that
>> > >> anyway, becuase what would we do, substitute the namespace for the
>> > >> prefix? Then our css would be huge. :) Maybe some day the browsers
>> > >> would work with the @namespace, and when that happens we can render
>> > >> it out to our css.
>> > >>
>> > >> >
>> > >> > - Jeanne
>> > >> >
>> > >> >>
>> > >> >> >
>> > >> >> >Regards
>> > >> >> >
>> > >> >> >� Simon
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >Jeanne Waldman <jeanne.waldman@oracle.com >
>> > >> >> >2006-08-18 18:27
>> > >> >> >Please respond to adffaces-dev
>> > >> >> >
>> > >> >> > To: adffaces-dev@incubator.apache.org
>> > >> >> > cc:
>> > >> >> > Subject: Re: ADFFACES-49
>> > >> inputText::content:required or
>> > >> >> >inputText:required::content
>> > >> >> >
>> > >> >> >
>> > >> >> >see inline for some random thoughts. :) I'm glad you brought
>> > >> this up,
>> > >> >> >because I need to come up with a solution soon for our internal
>> > >> project
>> > >> >> >that we are working on so that our developers can write their
>> > >> renderers
>> > >> >> >correctly.
>> > >> >> >
>> > >> >> >Simon_Lessard@DMR.CA wrote:
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >>Hello all,
>> > >> >> >>
>> > >> >> >>I raised that issue a while back, but now it's a bit more
>> > important
>> > >> >> since
>> > >> >> >>
>> > >> >> >>
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >>I'm trying to finalize ADFFACES-49 issue. What selector
>> > >> >> >>synthax do
>> > >> you
>> > >> >> >>prefer for states:
>> > >> >> >>1.1. <component>::<subPart>:<state> 1.2.
>> > >> >> >><component>:<state>::<subPart>.
>> > >> >> >>
>> > >> >> >>
>> > >> >> >>
>> > >> >> >>
>> > >> >> >We use both syntaxes, and they mean different things.
>> > >> >> >
>> > >> >> >1.1 means this: The subPart of the component is in this state.
>> > >> >> >For example:
>> > >> >> >af|train::stop:disabled (when this train's stop is disabled,
>> > >> >> >af|then
>> > >> style
>> > >> >> >the stop like this)
>> > >> >> >af|train:disabled::stop (when the entire train is disabled,
>> > >> >> >af|style
>> > >> all
>> > >> >> >the stops like this)
>> > >> >> >
>> > >> >> >1.2 means this: The component is in this state, and this is the
>> > >> >> subpart.
>> > >> >> >For example:
>> > >> >> >af|inputText:disabled::content (when the af:inputText
>> > >> disabled="true",
>> > >> >> >then style the content piece like this)
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >>I prefer the former and it's easier to implement. However, we
>> > >> already
>> > >> >> >>
>> > >> >> >>
>> > >> >> >have
>> > >> >> >
>> > >> >> >
>> > >> >> >>some :disabled that use the latter synthax.
>> > >> >> >>
>> > >> >> >>Secondly, there's also the issue raised by Jeanne, how should
>> > >> >> >>we
>> > >> >> manage
>> > >> >> >>which states are intercepted and which should pass through and
>> > >> >> >>be
>> > >> >> copied
>> > >> >> >>in the final CSS:
>> > >> >> >>2.1. Use a component specific list, so that :disabled could
>> > >> >> >>pass
>> > >> >> through
>> > >> >>
>> > >> >> >>for some components but get intercepted for some others? If
>> > >> >> >>that
>> > >> >> solution
>> > >> >> >>
>> > >> >> >>
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >>is selected, how/where should we configure that list, in the
>> > >> >> >>faces-config's metadata?
>> > >> >> >>
>> > >> >> >>
>> > >> >> >>
>> > >> >> >>
>> > >> >> >I like this one the best because let's say I use :disabled and
>> > >> >> >I intercept it and do some funky things with it. Then let's say
>> > >> >> >I
>> > >> decide
>> > >> >> >that the css spec deals
>> > >> >> >with :disabled perfectly fine, and I don't need to intercept
>> it.
>> > >> >> >Also, let's say :hover and :active work great on some dom
>> > >> >> >elements,
>> > >> but
>> > >> >> >do they work for everything?
>> > >> >> >Let's say I have this: <span class="myText">Hello!</span> and
>> > >> >> >this
>> > >> css:
>> > >> >> >.myText {color: black}
>> > >> >> >.myText:hover {color:red}
>> > >> >> >Does this work? (not in my tests)
>> > >> >> >
>> > >> >> >But what if this represents a component. I might want them to
>> > >> >> >be
>> > >> >> able to
>> > >> >> >specify .myText:hover and have it work even if the built-in
>> > >> >> >browser support wasn't there.
>> > >> >> >So I would want
>> > >> >> >af|myComponent:hover to work.
>> > >> >> >I'd render this
>> > >> >> ><span class="af_myComponent p_AFHover">Hello!</span> when they
>> > >> >> >are hovering over my span.
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >>2.2. Use a list of pseudo-classes passing through for all
>> > >> components.
>> > >> >> >>
>> > >> >> >>
>> > >> >> >Such
>> > >> >> >
>> > >> >> >
>> > >> >> >>list would have to be based on W3C, but as Jeanne observed,
>> > >> >> >>such
>> > >> list
>> > >> >> >>would break our :disabled that we're intercepting currently
>> > >> >> >>and
>> > >> could
>> > >> >> >>
>> > >> >> >>
>> > >> >> >lead
>> > >> >> >
>> > >> >> >
>> > >> >> >>to som.e problems if more pseudo-classes are added in future
>> > >> >> version of
>> > >> >> >>CSS.
>> > >> >> >>
>> > >> >> >>
>> > >> >> >>
>> > >> >> >>
>> > >> >> >Yes, I'd have to change the name of :disabled. But so far that
>> > >> >> >is
>> > >> the
>> > >> >> >only css valid pseudo-class that I use to date.
>> > >> >> >We have others like :hover (see above... if we don't want this
>> > >> >> >to
>> > >> pass
>> > >> >> >through, we'll need to change it to something else).
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >>2.3. Use a static list of pseudo-classes to intercept used by
>> > >> >> >>all components? If so, where should we place it? This solution
>> > probably
>> > >> >> has
>> > >> >> >>the same flaws as 2.2 if a new pseudo-classes i nthe CSS
>> > >> specification
>> > >> >> >>matches a name defined in the intercept list.
>> > >> >> >>2.4. Use a prefix for intercepted pseudo-classes like the
>> > >> >> >>-ora-
>> > >> >> used for
>> > >> >>
>> > >> >> >>properties?
>> > >> >> >>
>> > >> >> >>
>> > >> >> >>
>> > >> >> >>
>> > >> >> >I like this second best. If we did this, then I'd suggest that
>> > >> >> >we
>> > >> also
>> > >> >> >prefix the pseudo-elements.
>> > >> >> >The problem is, taking my :hover example, some components might
>> > >> >> >be rendered such that the browser automatically works with
>> > >> >> >:hover on the generated css, but others
>> > >> don't,
>> > >> >> >so those that don't have to have :-tri-hover ?
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >>My votes are:
>> > >> >> >>+1 for 1.1
>> > >> >> >>+1 for 2.2, but I would not place states resolvable during
>> > >> >> rendering in
>> > >> >> >>that list, so that disabled is still intercepted.
>> > >> >> >>
>> > >> >> >>
>> > >> >> >>
>> > >> >> >>
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >>
>> > >> >>
>> > >> >
>> > >>
>> > >>
>> > >
>> >
>> >
>>
>>
>>
Re: ADFFACES-49 inputText::content:required or inputText:required::content
Posted by Simon Lessard <si...@gmail.com>.
Hello Pavitra,
My solution would work with it as it is binary, the pseudo-class either get
intercepted or pass through, independently of the enclosing element. For
:hover case, it would always go through for Firefox, except if the component
said he wanted to intercept that pseudo-class and for IE it would always get
intercepted, even on <a /> element since the JavaScript required to emulate
a pseudo-class should always be the same, independently of the element.
So in your case, it would not work. However, I wonder why you would want to
intercept it in a case and not in the other as it only remove flexibility
for the end user imho. Can you explain the reason a bit more please?
Regards,
~ Simon
On 8/23/06, Pavitra Subramaniam <pa...@oracle.com> wrote:
>
> Hello Jeanne and Simon,
>
> There could be cases where intercepted states for a component or it's
> sub-part need to be considered together rather than individually. Or in some
> case it might be too early for even the renderer to provide a valid
> interceptor-state list at init time. The best time may be at rendering time.
>
> For instance, let's assume that the component sub-part "af|train::stop"
> can be in the following states :visited and :selected states.
>
> At runtime if the stop is selected, it may be rendered as a span and as an
> anchor, <a >, if it was visited before (and hence clickable). Both these
> elements may want to support the :hover pseudo-class.
>
> If I wanted the :hover to pass through if it's for selected stop (for the
> <span>) and intercept :hover if it's for a stop that is visited (link),
> would the proposed solution work?
>
>
> Thanks
> - Pavitra
>
> -----Original Message-----
> From: Simon Lessard [mailto:simon.lessard.3@gmail.com]
> Sent: Wednesday, August 23, 2006 6:28 AM
> To: adffaces-dev@incubator.apache.org
> Subject: Re: ADFFACES-49 inputText::content:required or
> inputText:required::content
>
> Hello Jeanne,
>
> Yes I'm aware that states can go on the component's sub-part, but are you
> suggesting that we extends the concept to be flexible enough to allow
> thecomponent to intercept a given state on the root element but not on the
> sub-part? e.g. inputText would intercept :disabled when placed on
> af|inputText but not on af|inputText::content? That's some complexity
> af|but
> it's doable I guess.
>
>
> Regards,
>
> ~Simon
>
> On 8/22/06, Jeanne Waldman <je...@oracle.com> wrote:
> >
> > I agree that only the renderers should know what states they want to
> > intercept. I was thinking we add this information in the renderer .xml
> > file and then when we build our classes, we can put this information
> > somewhere -- not sure where.
> >
> > I'm sure you realize this, but just in case... the states do not have
> > to go on the root dom element, they can go on sub-root elements, like
> > af|train::stop:disabled.
> >
> > Simon Lessard wrote:
> >
> > > Hmmm, I'm leaning toward the per component basis option more and more.
> > > However, I hate static lists and additional config files are not all
> > that
> > > great. I see a possibility though. Maybe it will work, but I did not
> > > explore that area much yet so I might say something stupid.
> > > Currently it seem to me that skins are linked to the renderkit. So,
> > > how feasible would it be to create a SkinRenderKitFactory that
> > > would, before giving away any renderer, would populate a
> > > Map<component, list<state>> be interrogating all renderers in the
> > > kit. That way, when StyleSheetRenderer would do its work, we would
> > > be sure that the list is populated. Also, with that solution, only
> > > the renderers would have to know what states they want to intercept.
> > > This also fix the synchronization issue, changing the kit or the
> > > renderer would automatically update the interception list. We would
> > > have to create a
> > new
> > > BaseRenderer in the API however. I see two additional methods needed
> > > for such renderers:
> > >
> > > public String getComponentName() // or I guess getRootStyleClass
> > > would work just as well public List<String> getInterceptedStates();
> > > // Returning the list of states to intercept.
> > >
> > >
> > > Makes sense?
> > >
> > > ~ Simon
> > >
> > > On 8/21/06, Jeanne Waldman <je...@oracle.com> wrote:
> > >
> > >>
> > >> More comments inline.
> > >> Which way are you leaning?
> > >>
> > >> - Jeanne
> > >>
> > >> Simon Lessard wrote:
> > >>
> > >> > Hello Jeanne,
> > >> >
> > >> > Thanks for the complete answer.
> > >> >
> > >> > On 8/21/06, Jeanne Waldman <jeanne.waldman@oracle.com > wrote:
> > >> >
> > >> >>
> > >> >> Hi Simon,
> > >> >> Thanks for the email.
> > >> >>
> > >> >> Simon_Lessard@DMR.CA wrote:
> > >> >>
> > >> >> >>We use both syntaxes, and they mean different things.
> > >> >> >>For example:
> > >> >> >>af|train::stop:disabled (when this train's stop is disabled,
> > >> >> >>af|then
> > >> >> style
> > >> >> >>the stop like this)
> > >> >> >>af|train:disabled::stop (when the entire train is disabled,
> > >> style all
> > >> >> >>the stops like this)
> > >> >> >>
> > >> >> >>
> > >> >> >
> > >> >> >Agreed.
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >>Let's say I have this: <span class="myText">Hello!</span> and
> > >> >> >>this
> > >> >> css:
> > >> >> >>.myText {color: black}
> > >> >> >>.myText:hover {color:red}
> > >> >> >>Does this work? (not in my tests)
> > >> >> >>
> > >> >> >>
> > >> >> >
> > >> >> >It works in Firefox, not IE, as usual. W3C specifies that
> > >> >> >:hover
> > >> should
> > >> >> >work with everything, but it's not like all browsers will
> > >> >> >support everything W3C says anytime soon. Maybe we should
> > >> >> >intercept all pseudo-classes, if it can be resolved on Java
> > >> >> >side (like
> > :disabled),
> > >> we
> > >> >> >resolve it there and it never pass through so we prevent all
> > >> >> >bad
> > >> >> support
> > >> >> >from the browser. For states that cannot be resolved in Java,
> > >> >> >we
> > >> could
> > >> >> ask
> > >> >> >the Agent if it supports the specified pseudo-class for the
> > >> generated
> > >> >> >element (link:hover works in IE, but not on anything else). If
> > >> >> >the
> > >> >> agent
> > >> >> >supports it, we let the class pass through to the generated CSS
> > >> >> file, if
> > >> >> >the agent does not, then we could add some JS code to emulate it.
> > >> >> >
> > >> >> >
> > >> >> We generate the css file before we render the components, so
> > >> >> when
> > you
> > >> >> say we should intercept all pseudo-classes and if it can be
> > >> resolved on
> > >> >> the Java side, we should resolve it. But how would we know at
> > >> >> this
> > >> point
> > >> >> where we are going to render the pseudo-class? that af|foo:hover
> > will
> > >> be
> > >> >> generated on a link? Maybe af|foo:hover is on a <span>, but
> > >> >> af|foo::step:hover is on the link. (we would know if we kept the
> > >> >> skinning-key -> pseudo-class to resolve map). Or do you mean
> > >> literally
> > >> >> that if we can resolve it on the Java side -- even if the
> > >> >> browser
> > can
> > >> as
> > >> >> well -- we go ahead and do that?
> > >> >
> > >> >
> > >> >
> > >> > I mean litterally that we make a list of pseudo-classes that we
> > >> > know we can always resolve during rendering, like :disabled, and
> > >> > always intercept it. In a sense it would be a way to cover
> > >> > browsers' lack of support for
> > those
> > >> > pseudo-classes.
> > >> >
> > >> > In the case of :hover, do we pass that through for IE or not?
> > >> > Let's
> > >> say
> > >> >
> > >> >> we don't pass it through for IE. Then we'll need some code that
> > >> >> gets :hover and says, oh, we are on IE, so don't pass this
> > >> >> through but instead do some onmouseover + css magic. This seems
> > >> >> like it could
> > get
> > >> >> messy fast.
> > >> >
> > >> >
> > >> >
> > >> > Fair point, the renderers would have to check if there's a
> > >> > selector
> > >> using
> > >> > :hover defined in the current skin and add some JS, it's messy
> > indeed.
> > >> >
> > >> >> The main problem I have the "per component" option is the
> > >> >> potential
> > >> >> >performance overhaul it represents as well as the increased
> > >> component
> > >> >> >development complexity (since you have to put more information
> > >> >> >in
> > >> the
> > >> >> >metadata).
> > >> >> >
> > >> >> >
> > >> >> I don't think of this as a performance hit, since this will
> > >> >> happen
> > at
> > >> >> the css generation time, not with every renderer. And we cache
> > >> >> the generated css file.
> > >> >> It would be like the map I have now in FileSystemStyleCache.
> > >> >
> > >> >
> > >> >
> > >> > Small question here. When is the CSS generated exactly? Is it at
> > >> > startup or at the first request for a given skin family? If it is
> > >> > during
> > startup,
> > >> > the
> > >> > performance hit is indeed a non issue.
> > >>
> > >> rendered in StyleSheetRenderer. We get it out of the cache if it is
> > >> there, otherwise we generate it.
> > >>
> > >> >
> > >> > However, we would need to keep the renderer and this map in sync.
> > >> For my
> > >> >
> > >> >> renderer 'foo', I know that I want to handle 'hover' myself, so
> > >> >> I
> > put
> > >> >> the hover -> p_AFHover in the map that will be consulted when we
> > >> >> generate the css file. af|foo:hover does not pass through. All
> > >> >> other :hover passes through. I don't think this is that
> > >> >> terrible. I like
> > >> this
> > >> >> better than the prefix, because if, down the line, we decide
> > >> >> that we
> > >> can
> > >> >> pass through the pseudo-class, the user's skin will not have to
> > >> change,
> > >> >> but our code will get simpler.
> > >> >
> > >> >
> > >> >
> > >> > Not that bad, but I kind of dislike hard coded lists as component
> > >> > developers won't be able to use the skinning feature without
> > >> > giving it to
> > >> Trinidad
> > >> > project since they will have to hack Trinidad's jar file to add
> > >> > their
> > >> own
> > >> > states to the map. If that way is chosen, I would rather use
> > >> > another configuration file or some faces-config meta-data
> > >> > entries. For now skin is not a public API, but I'm prety sure it
> > >> > will become one at some
> > >> point in
> > >> > time.
> > >>
> > >> We definitely need to get it out of FileSystemStyleCache. No doubt
> > about
> > >> it.
> > >>
> > >> >
> > >> >> The prefix is ok, but I find it a bit counter intuitive since
> > >> >> the user has
> > >> >> >to know which states will be handled by browser and which are
> > >> >> managed by
> > >> >> >Trinidad. I would prefer to hide that kind of low level
> > >> implementation
> > >> >> >details to skinners.
> > >> >> >
> > >> >> >
> > >> >> We would definitely document all the -tri- pseudo-classes per
> > >> skinning
> > >> >> key. For example:
> > >> >> af|inputText:-tri-required, af|inputText:-tri-read-only,
> > >> >> af|inputText:-tri-disabled. But for af|train::stop-link,
> > >> >> we'd document that they can use :hover.
> > >> >
> > >> >
> > >> >
> > >> > It works, but it's a bit ugly imho. Furthermore, as you pointed
> > >> > out,
> > >> such
> > >> > solution would force skin CSS changes if we beside to let any
> > >> > given
> > >> state
> > >> > pass through in the future.
> > >>
> > >> true.
> > >>
> > >> >
> > >> >> On a side note that could lead to a new post, what should we do
> > >> >> with
> > >> >> >icons? Currently the engine considers a selector an icon one if
> > >> >> >it
> > >> ends
> > >> >> >with -icon. This lead to some strange selectors sometimes like
> > >> >> >-icon-style-class simply to prevent the parser to interpret it
> > >> >> >as
> > an
> > >> >> icon.
> > >> >> >Maybe we should add something like :::icon, ::tri-icon or --icon?
> > >> That
> > >> >> way
> > >> >> >there will be no ambiguity left.
> > >> >> >
> > >> >> >
> > >> >> I don't have a problem with saying -icon-style when what you
> > >> >> mean is that you want to style the icon, and ending the key with
> > >> >> -icon
> > >> when it
> > >> >> means an icon.
> > >> >
> > >> >
> > >> >
> > >> > It's not that bad, true, but do we have a doc somewhere to
> > >> > document
> > >> this
> > >> > kind of skinning rules? If not, should I add a wiki entry for it
> > >> > even if the API is not public yet? Other things interesting I see
> > >> > are
> > >> FileSystemCache
> > >> > and the mandatory "af" namespace.
> > >>
> > >> We don't have a skinning document for Trinidad developers (as
> > >> opposed
> > to
> > >> application developers using Trinidad).
> > >> Starting a wiki would be great. I can populate it with some
> > >> information I have.
> > >>
> > >> Yeah, the namespace is purely to make it so that the skinner knows
> > there
> > >> are Trinidad keys.
> > >> We need to change these to tr for one thing. The code might be a
> > >> little bit hardcoded to use 'af', so that will need to change.
> > >> We don't honor the actual namespace in that you can't add
> > >> @namespace to the top of the css file and then be able to use
> > >> whatever prefix you want. That was very low priority when I was
> > >> doing the skinning, and I'm not so sure we'd want to do that
> > >> anyway, becuase what would we do, substitute the namespace for the
> > >> prefix? Then our css would be huge. :) Maybe some day the browsers
> > >> would work with the @namespace, and when that happens we can render
> > >> it out to our css.
> > >>
> > >> >
> > >> > - Jeanne
> > >> >
> > >> >>
> > >> >> >
> > >> >> >Regards
> > >> >> >
> > >> >> >� Simon
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >Jeanne Waldman <jeanne.waldman@oracle.com >
> > >> >> >2006-08-18 18:27
> > >> >> >Please respond to adffaces-dev
> > >> >> >
> > >> >> > To: adffaces-dev@incubator.apache.org
> > >> >> > cc:
> > >> >> > Subject: Re: ADFFACES-49
> > >> inputText::content:required or
> > >> >> >inputText:required::content
> > >> >> >
> > >> >> >
> > >> >> >see inline for some random thoughts. :) I'm glad you brought
> > >> this up,
> > >> >> >because I need to come up with a solution soon for our internal
> > >> project
> > >> >> >that we are working on so that our developers can write their
> > >> renderers
> > >> >> >correctly.
> > >> >> >
> > >> >> >Simon_Lessard@DMR.CA wrote:
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >>Hello all,
> > >> >> >>
> > >> >> >>I raised that issue a while back, but now it's a bit more
> > important
> > >> >> since
> > >> >> >>
> > >> >> >>
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >>I'm trying to finalize ADFFACES-49 issue. What selector
> > >> >> >>synthax do
> > >> you
> > >> >> >>prefer for states:
> > >> >> >>1.1. <component>::<subPart>:<state> 1.2.
> > >> >> >><component>:<state>::<subPart>.
> > >> >> >>
> > >> >> >>
> > >> >> >>
> > >> >> >>
> > >> >> >We use both syntaxes, and they mean different things.
> > >> >> >
> > >> >> >1.1 means this: The subPart of the component is in this state.
> > >> >> >For example:
> > >> >> >af|train::stop:disabled (when this train's stop is disabled,
> > >> >> >af|then
> > >> style
> > >> >> >the stop like this)
> > >> >> >af|train:disabled::stop (when the entire train is disabled,
> > >> >> >af|style
> > >> all
> > >> >> >the stops like this)
> > >> >> >
> > >> >> >1.2 means this: The component is in this state, and this is the
> > >> >> subpart.
> > >> >> >For example:
> > >> >> >af|inputText:disabled::content (when the af:inputText
> > >> disabled="true",
> > >> >> >then style the content piece like this)
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >>I prefer the former and it's easier to implement. However, we
> > >> already
> > >> >> >>
> > >> >> >>
> > >> >> >have
> > >> >> >
> > >> >> >
> > >> >> >>some :disabled that use the latter synthax.
> > >> >> >>
> > >> >> >>Secondly, there's also the issue raised by Jeanne, how should
> > >> >> >>we
> > >> >> manage
> > >> >> >>which states are intercepted and which should pass through and
> > >> >> >>be
> > >> >> copied
> > >> >> >>in the final CSS:
> > >> >> >>2.1. Use a component specific list, so that :disabled could
> > >> >> >>pass
> > >> >> through
> > >> >>
> > >> >> >>for some components but get intercepted for some others? If
> > >> >> >>that
> > >> >> solution
> > >> >> >>
> > >> >> >>
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >>is selected, how/where should we configure that list, in the
> > >> >> >>faces-config's metadata?
> > >> >> >>
> > >> >> >>
> > >> >> >>
> > >> >> >>
> > >> >> >I like this one the best because let's say I use :disabled and
> > >> >> >I intercept it and do some funky things with it. Then let's say
> > >> >> >I
> > >> decide
> > >> >> >that the css spec deals
> > >> >> >with :disabled perfectly fine, and I don't need to intercept it.
> > >> >> >Also, let's say :hover and :active work great on some dom
> > >> >> >elements,
> > >> but
> > >> >> >do they work for everything?
> > >> >> >Let's say I have this: <span class="myText">Hello!</span> and
> > >> >> >this
> > >> css:
> > >> >> >.myText {color: black}
> > >> >> >.myText:hover {color:red}
> > >> >> >Does this work? (not in my tests)
> > >> >> >
> > >> >> >But what if this represents a component. I might want them to
> > >> >> >be
> > >> >> able to
> > >> >> >specify .myText:hover and have it work even if the built-in
> > >> >> >browser support wasn't there.
> > >> >> >So I would want
> > >> >> >af|myComponent:hover to work.
> > >> >> >I'd render this
> > >> >> ><span class="af_myComponent p_AFHover">Hello!</span> when they
> > >> >> >are hovering over my span.
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >>2.2. Use a list of pseudo-classes passing through for all
> > >> components.
> > >> >> >>
> > >> >> >>
> > >> >> >Such
> > >> >> >
> > >> >> >
> > >> >> >>list would have to be based on W3C, but as Jeanne observed,
> > >> >> >>such
> > >> list
> > >> >> >>would break our :disabled that we're intercepting currently
> > >> >> >>and
> > >> could
> > >> >> >>
> > >> >> >>
> > >> >> >lead
> > >> >> >
> > >> >> >
> > >> >> >>to som.e problems if more pseudo-classes are added in future
> > >> >> version of
> > >> >> >>CSS.
> > >> >> >>
> > >> >> >>
> > >> >> >>
> > >> >> >>
> > >> >> >Yes, I'd have to change the name of :disabled. But so far that
> > >> >> >is
> > >> the
> > >> >> >only css valid pseudo-class that I use to date.
> > >> >> >We have others like :hover (see above... if we don't want this
> > >> >> >to
> > >> pass
> > >> >> >through, we'll need to change it to something else).
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >>2.3. Use a static list of pseudo-classes to intercept used by
> > >> >> >>all components? If so, where should we place it? This solution
> > probably
> > >> >> has
> > >> >> >>the same flaws as 2.2 if a new pseudo-classes i nthe CSS
> > >> specification
> > >> >> >>matches a name defined in the intercept list.
> > >> >> >>2.4. Use a prefix for intercepted pseudo-classes like the
> > >> >> >>-ora-
> > >> >> used for
> > >> >>
> > >> >> >>properties?
> > >> >> >>
> > >> >> >>
> > >> >> >>
> > >> >> >>
> > >> >> >I like this second best. If we did this, then I'd suggest that
> > >> >> >we
> > >> also
> > >> >> >prefix the pseudo-elements.
> > >> >> >The problem is, taking my :hover example, some components might
> > >> >> >be rendered such that the browser automatically works with
> > >> >> >:hover on the generated css, but others
> > >> don't,
> > >> >> >so those that don't have to have :-tri-hover ?
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >>My votes are:
> > >> >> >>+1 for 1.1
> > >> >> >>+1 for 2.2, but I would not place states resolvable during
> > >> >> rendering in
> > >> >> >>that list, so that disabled is still intercepted.
> > >> >> >>
> > >> >> >>
> > >> >> >>
> > >> >> >>
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >>
> > >> >>
> > >> >
> > >>
> > >>
> > >
> >
> >
>
>
>
Re: ADFFACES-49 inputText::content:required or inputText:required::content
Posted by Simon Lessard <si...@gmail.com>.
Hello Jeanne,
Yah I saw that, the patch I uploaded for this issue uses that code already.
Regards,
~ Simon
On 8/24/06, Jeanne Waldman <je...@oracle.com> wrote:
>
> I wasn't really suggesting anything.
>
> By the way, in case you didn't notice, Adam made a change yesterday so
> that ALL pseudo-classes get transformed to .p_AF*, except for the css-2
> pseudo-classes, which pass through.
>
> This simple change buys us a lot. It satisfies my immediate need for a
> pseudo-class solution, and it heads us in the right direction, in that
> the pseudo-class api doesn't have to change when we implement the full
> solution that gives the component developer's more flexibility.
>
> Thanks, Adam!
>
> - Jeanne
>
> Simon Lessard wrote:
>
> > Hello Jeanne,
> >
> > Yes I'm aware that states can go on the component's sub-part, but are
> you
> > suggesting that we extends the concept to be flexible enough to allow
> > thecomponent to intercept a given state on the root element but not on
> > the
> > sub-part? e.g. inputText would intercept :disabled when placed on
> > af|inputText but not on af|inputText::content? That's some complexity
> but
> > it's doable I guess.
> >
> >
> > Regards,
> >
> > ~Simon
> >
> > On 8/22/06, Jeanne Waldman <je...@oracle.com> wrote:
> >
> >>
> >> I agree that only the renderers should know what states they want to
> >> intercept. I was thinking we add this information in the renderer .xml
> >> file and then when we build our classes, we can put this information
> >> somewhere -- not sure where.
> >>
> >> I'm sure you realize this, but just in case... the states do not have
> to
> >> go on the root dom element, they can go on sub-root elements, like
> >> af|train::stop:disabled.
> >>
> >> Simon Lessard wrote:
> >>
> >> > Hmmm, I'm leaning toward the per component basis option more and
> more.
> >> > However, I hate static lists and additional config files are not all
> >> that
> >> > great. I see a possibility though. Maybe it will work, but I did not
> >> > explore
> >> > that area much yet so I might say something stupid. Currently it seem
> >> > to me
> >> > that skins are linked to the renderkit. So, how feasible would it
> >> be to
> >> > create a SkinRenderKitFactory that would, before giving away any
> >> > renderer,
> >> > would populate a Map<component, list<state>> be interrogating all
> >> > renderers
> >> > in the kit. That way, when StyleSheetRenderer would do its work, we
> >> > would be
> >> > sure that the list is populated. Also, with that solution, only the
> >> > renderers would have to know what states they want to intercept. This
> >> > also
> >> > fix the synchronization issue, changing the kit or the renderer would
> >> > automatically update the interception list. We would have to create a
> >> new
> >> > BaseRenderer in the API however. I see two additional methods
> >> needed for
> >> > such renderers:
> >> >
> >> > public String getComponentName() // or I guess getRootStyleClass
> would
> >> > work
> >> > just as well
> >> > public List<String> getInterceptedStates(); // Returning the list of
> >> > states
> >> > to intercept.
> >> >
> >> >
> >> > Makes sense?
> >> >
> >> > ~ Simon
> >> >
> >> > On 8/21/06, Jeanne Waldman <je...@oracle.com> wrote:
> >> >
> >> >>
> >> >> More comments inline.
> >> >> Which way are you leaning?
> >> >>
> >> >> - Jeanne
> >> >>
> >> >> Simon Lessard wrote:
> >> >>
> >> >> > Hello Jeanne,
> >> >> >
> >> >> > Thanks for the complete answer.
> >> >> >
> >> >> > On 8/21/06, Jeanne Waldman <jeanne.waldman@oracle.com > wrote:
> >> >> >
> >> >> >>
> >> >> >> Hi Simon,
> >> >> >> Thanks for the email.
> >> >> >>
> >> >> >> Simon_Lessard@DMR.CA wrote:
> >> >> >>
> >> >> >> >>We use both syntaxes, and they mean different things.
> >> >> >> >>For example:
> >> >> >> >>af|train::stop:disabled (when this train's stop is disabled,
> >> then
> >> >> >> style
> >> >> >> >>the stop like this)
> >> >> >> >>af|train:disabled::stop (when the entire train is disabled,
> >> >> style all
> >> >> >> >>the stops like this)
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> >Agreed.
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >>Let's say I have this: <span class="myText">Hello!</span> and
> >> this
> >> >> >> css:
> >> >> >> >>.myText {color: black}
> >> >> >> >>.myText:hover {color:red}
> >> >> >> >>Does this work? (not in my tests)
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> >It works in Firefox, not IE, as usual. W3C specifies that :hover
> >> >> should
> >> >> >> >work with everything, but it's not like all browsers will
> support
> >> >> >> >everything W3C says anytime soon. Maybe we should intercept all
> >> >> >> >pseudo-classes, if it can be resolved on Java side (like
> >> :disabled),
> >> >> we
> >> >> >> >resolve it there and it never pass through so we prevent all bad
> >> >> >> support
> >> >> >> >from the browser. For states that cannot be resolved in Java, we
> >> >> could
> >> >> >> ask
> >> >> >> >the Agent if it supports the specified pseudo-class for the
> >> >> generated
> >> >> >> >element (link:hover works in IE, but not on anything else). If
> >> the
> >> >> >> agent
> >> >> >> >supports it, we let the class pass through to the generated CSS
> >> >> >> file, if
> >> >> >> >the agent does not, then we could add some JS code to emulate
> it.
> >> >> >> >
> >> >> >> >
> >> >> >> We generate the css file before we render the components, so when
> >> you
> >> >> >> say we should intercept all pseudo-classes and if it can be
> >> >> resolved on
> >> >> >> the Java side, we should resolve it. But how would we know at
> this
> >> >> point
> >> >> >> where we are going to render the pseudo-class? that af|foo:hover
> >> will
> >> >> be
> >> >> >> generated on a link? Maybe af|foo:hover is on a <span>, but
> >> >> >> af|foo::step:hover is on the link. (we would know if we kept the
> >> >> >> skinning-key -> pseudo-class to resolve map). Or do you mean
> >> >> literally
> >> >> >> that if we can resolve it on the Java side -- even if the browser
> >> can
> >> >> as
> >> >> >> well -- we go ahead and do that?
> >> >> >
> >> >> >
> >> >> >
> >> >> > I mean litterally that we make a list of pseudo-classes that we
> >> know
> >> >> > we can
> >> >> > always resolve during rendering, like :disabled, and always
> >> intercept
> >> >> > it. In
> >> >> > a sense it would be a way to cover browsers' lack of support for
> >> those
> >> >> > pseudo-classes.
> >> >> >
> >> >> > In the case of :hover, do we pass that through for IE or not?
> Let's
> >> >> say
> >> >> >
> >> >> >> we don't pass it through for IE. Then we'll need some code that
> >> gets
> >> >> >> :hover and says, oh, we are on IE, so don't pass this through but
> >> >> >> instead do some onmouseover + css magic. This seems like it could
> >> get
> >> >> >> messy fast.
> >> >> >
> >> >> >
> >> >> >
> >> >> > Fair point, the renderers would have to check if there's a
> selector
> >> >> using
> >> >> > :hover defined in the current skin and add some JS, it's messy
> >> indeed.
> >> >> >
> >> >> >> The main problem I have the "per component" option is the
> >> potential
> >> >> >> >performance overhaul it represents as well as the increased
> >> >> component
> >> >> >> >development complexity (since you have to put more information
> in
> >> >> the
> >> >> >> >metadata).
> >> >> >> >
> >> >> >> >
> >> >> >> I don't think of this as a performance hit, since this will
> happen
> >> at
> >> >> >> the css generation time, not with every renderer. And we cache
> the
> >> >> >> generated css file.
> >> >> >> It would be like the map I have now in FileSystemStyleCache.
> >> >> >
> >> >> >
> >> >> >
> >> >> > Small question here. When is the CSS generated exactly? Is it at
> >> >> > startup or
> >> >> > at the first request for a given skin family? If it is during
> >> startup,
> >> >> > the
> >> >> > performance hit is indeed a non issue.
> >> >>
> >> >> rendered in StyleSheetRenderer. We get it out of the cache if it is
> >> >> there, otherwise we generate it.
> >> >>
> >> >> >
> >> >> > However, we would need to keep the renderer and this map in sync.
> >> >> For my
> >> >> >
> >> >> >> renderer 'foo', I know that I want to handle 'hover' myself, so I
> >> put
> >> >> >> the hover -> p_AFHover in the map that will be consulted when we
> >> >> >> generate the css file. af|foo:hover does not pass through. All
> >> other
> >> >> >> :hover passes through. I don't think this is that terrible. I
> like
> >> >> this
> >> >> >> better than the prefix, because if, down the line, we decide
> >> that we
> >> >> can
> >> >> >> pass through the pseudo-class, the user's skin will not have to
> >> >> change,
> >> >> >> but our code will get simpler.
> >> >> >
> >> >> >
> >> >> >
> >> >> > Not that bad, but I kind of dislike hard coded lists as component
> >> >> > developers
> >> >> > won't be able to use the skinning feature without giving it to
> >> >> Trinidad
> >> >> > project since they will have to hack Trinidad's jar file to add
> >> their
> >> >> own
> >> >> > states to the map. If that way is chosen, I would rather use
> >> another
> >> >> > configuration file or some faces-config meta-data entries. For now
> >> >> > skin is
> >> >> > not a public API, but I'm prety sure it will become one at some
> >> >> point in
> >> >> > time.
> >> >>
> >> >> We definitely need to get it out of FileSystemStyleCache. No doubt
> >> about
> >> >> it.
> >> >>
> >> >> >
> >> >> >> The prefix is ok, but I find it a bit counter intuitive since the
> >> >> >> user has
> >> >> >> >to know which states will be handled by browser and which are
> >> >> >> managed by
> >> >> >> >Trinidad. I would prefer to hide that kind of low level
> >> >> implementation
> >> >> >> >details to skinners.
> >> >> >> >
> >> >> >> >
> >> >> >> We would definitely document all the -tri- pseudo-classes per
> >> >> skinning
> >> >> >> key. For example:
> >> >> >> af|inputText:-tri-required, af|inputText:-tri-read-only,
> >> >> >> af|inputText:-tri-disabled. But for af|train::stop-link,
> >> >> >> we'd document that they can use :hover.
> >> >> >
> >> >> >
> >> >> >
> >> >> > It works, but it's a bit ugly imho. Furthermore, as you pointed
> >> out,
> >> >> such
> >> >> > solution would force skin CSS changes if we beside to let any
> given
> >> >> state
> >> >> > pass through in the future.
> >> >>
> >> >> true.
> >> >>
> >> >> >
> >> >> >> On a side note that could lead to a new post, what should we do
> >> with
> >> >> >> >icons? Currently the engine considers a selector an icon one
> >> if it
> >> >> ends
> >> >> >> >with -icon. This lead to some strange selectors sometimes like
> >> >> >> >-icon-style-class simply to prevent the parser to interpret it
> as
> >> an
> >> >> >> icon.
> >> >> >> >Maybe we should add something like :::icon, ::tri-icon or
> --icon?
> >> >> That
> >> >> >> way
> >> >> >> >there will be no ambiguity left.
> >> >> >> >
> >> >> >> >
> >> >> >> I don't have a problem with saying -icon-style when what you
> >> mean is
> >> >> >> that you want to style the icon, and ending the key with -icon
> >> >> when it
> >> >> >> means an icon.
> >> >> >
> >> >> >
> >> >> >
> >> >> > It's not that bad, true, but do we have a doc somewhere to
> document
> >> >> this
> >> >> > kind of skinning rules? If not, should I add a wiki entry for it
> >> even
> >> >> > if the
> >> >> > API is not public yet? Other things interesting I see are
> >> >> FileSystemCache
> >> >> > and the mandatory "af" namespace.
> >> >>
> >> >> We don't have a skinning document for Trinidad developers (as
> opposed
> >> to
> >> >> application developers using Trinidad).
> >> >> Starting a wiki would be great. I can populate it with some
> >> information
> >> >> I have.
> >> >>
> >> >> Yeah, the namespace is purely to make it so that the skinner knows
> >> there
> >> >> are Trinidad keys.
> >> >> We need to change these to tr for one thing. The code might be a
> >> little
> >> >> bit hardcoded to use 'af', so that will need to change.
> >> >> We don't honor the actual namespace in that you can't add
> >> @namespace to
> >> >> the top of the css file and then be able to use
> >> >> whatever prefix you want. That was very low priority when I was
> doing
> >> >> the skinning, and I'm not so sure we'd want to do that
> >> >> anyway, becuase what would we do, substitute the namespace for the
> >> >> prefix? Then our css would be huge. :) Maybe some day the
> >> >> browsers would work with the @namespace, and when that happens we
> can
> >> >> render it out to our css.
> >> >>
> >> >> >
> >> >> > - Jeanne
> >> >> >
> >> >> >>
> >> >> >> >
> >> >> >> >Regards
> >> >> >> >
> >> >> >> >� Simon
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >Jeanne Waldman <jeanne.waldman@oracle.com >
> >> >> >> >2006-08-18 18:27
> >> >> >> >Please respond to adffaces-dev
> >> >> >> >
> >> >> >> > To: adffaces-dev@incubator.apache.org
> >> >> >> > cc:
> >> >> >> > Subject: Re: ADFFACES-49
> >> >> inputText::content:required or
> >> >> >> >inputText:required::content
> >> >> >> >
> >> >> >> >
> >> >> >> >see inline for some random thoughts. :) I'm glad you brought
> >> >> this up,
> >> >> >> >because I need to come up with a solution soon for our internal
> >> >> project
> >> >> >> >that we are working on so that our developers can write their
> >> >> renderers
> >> >> >> >correctly.
> >> >> >> >
> >> >> >> >Simon_Lessard@DMR.CA wrote:
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >>Hello all,
> >> >> >> >>
> >> >> >> >>I raised that issue a while back, but now it's a bit more
> >> important
> >> >> >> since
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >>I'm trying to finalize ADFFACES-49 issue. What selector
> >> synthax do
> >> >> you
> >> >> >> >>prefer for states:
> >> >> >> >>1.1. <component>::<subPart>:<state>
> >> >> >> >>1.2. <component>:<state>::<subPart>.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >We use both syntaxes, and they mean different things.
> >> >> >> >
> >> >> >> >1.1 means this: The subPart of the component is in this state.
> >> >> >> >For example:
> >> >> >> >af|train::stop:disabled (when this train's stop is disabled,
> then
> >> >> style
> >> >> >> >the stop like this)
> >> >> >> >af|train:disabled::stop (when the entire train is disabled,
> style
> >> >> all
> >> >> >> >the stops like this)
> >> >> >> >
> >> >> >> >1.2 means this: The component is in this state, and this is the
> >> >> >> subpart.
> >> >> >> >For example:
> >> >> >> >af|inputText:disabled::content (when the af:inputText
> >> >> disabled="true",
> >> >> >> >then style the content piece like this)
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >>I prefer the former and it's easier to implement. However, we
> >> >> already
> >> >> >> >>
> >> >> >> >>
> >> >> >> >have
> >> >> >> >
> >> >> >> >
> >> >> >> >>some :disabled that use the latter synthax.
> >> >> >> >>
> >> >> >> >>Secondly, there's also the issue raised by Jeanne, how should
> we
> >> >> >> manage
> >> >> >> >>which states are intercepted and which should pass through
> >> and be
> >> >> >> copied
> >> >> >> >>in the final CSS:
> >> >> >> >>2.1. Use a component specific list, so that :disabled could
> pass
> >> >> >> through
> >> >> >>
> >> >> >> >>for some components but get intercepted for some others? If
> that
> >> >> >> solution
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >>is selected, how/where should we configure that list, in the
> >> >> >> >>faces-config's metadata?
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >I like this one the best because let's say I use :disabled and I
> >> >> >> >intercept it and do some funky things with it. Then let's say I
> >> >> decide
> >> >> >> >that the css spec deals
> >> >> >> >with :disabled perfectly fine, and I don't need to intercept it.
> >> >> >> >Also, let's say :hover and :active work great on some dom
> >> elements,
> >> >> but
> >> >> >> >do they work for everything?
> >> >> >> >Let's say I have this: <span class="myText">Hello!</span> and
> >> this
> >> >> css:
> >> >> >> >.myText {color: black}
> >> >> >> >.myText:hover {color:red}
> >> >> >> >Does this work? (not in my tests)
> >> >> >> >
> >> >> >> >But what if this represents a component. I might want them to be
> >> >> >> able to
> >> >> >> >specify .myText:hover and have it work even if the built-in
> >> browser
> >> >> >> >support wasn't there.
> >> >> >> >So I would want
> >> >> >> >af|myComponent:hover to work.
> >> >> >> >I'd render this
> >> >> >> ><span class="af_myComponent p_AFHover">Hello!</span>
> >> >> >> >when they are hovering over my span.
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >>2.2. Use a list of pseudo-classes passing through for all
> >> >> components.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >Such
> >> >> >> >
> >> >> >> >
> >> >> >> >>list would have to be based on W3C, but as Jeanne observed,
> such
> >> >> list
> >> >> >> >>would break our :disabled that we're intercepting currently and
> >> >> could
> >> >> >> >>
> >> >> >> >>
> >> >> >> >lead
> >> >> >> >
> >> >> >> >
> >> >> >> >>to som.e problems if more pseudo-classes are added in future
> >> >> >> version of
> >> >> >> >>CSS.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >Yes, I'd have to change the name of :disabled. But so far that
> is
> >> >> the
> >> >> >> >only css valid pseudo-class that I use to date.
> >> >> >> >We have others like :hover (see above... if we don't want this
> to
> >> >> pass
> >> >> >> >through, we'll need to change it to something else).
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >>2.3. Use a static list of pseudo-classes to intercept used by
> >> all
> >> >> >> >>components? If so, where should we place it? This solution
> >> probably
> >> >> >> has
> >> >> >> >>the same flaws as 2.2 if a new pseudo-classes i nthe CSS
> >> >> specification
> >> >> >> >>matches a name defined in the intercept list.
> >> >> >> >>2.4. Use a prefix for intercepted pseudo-classes like the -ora-
> >> >> >> used for
> >> >> >>
> >> >> >> >>properties?
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >I like this second best. If we did this, then I'd suggest that
> we
> >> >> also
> >> >> >> >prefix the pseudo-elements.
> >> >> >> >The problem is, taking my :hover example, some components
> >> might be
> >> >> >> >rendered such that the browser
> >> >> >> >automatically works with :hover on the generated css, but others
> >> >> don't,
> >> >> >> >so those that don't have to have
> >> >> >> >:-tri-hover ?
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >>My votes are:
> >> >> >> >>+1 for 1.1
> >> >> >> >>+1 for 2.2, but I would not place states resolvable during
> >> >> >> rendering in
> >> >> >> >>that list, so that disabled is still intercepted.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >> >
> >>
> >>
> >
>
>
Re: ADFFACES-49 inputText::content:required or inputText:required::content
Posted by Jeanne Waldman <je...@oracle.com>.
I wasn't really suggesting anything.
By the way, in case you didn't notice, Adam made a change yesterday so
that ALL pseudo-classes get transformed to .p_AF*, except for the css-2
pseudo-classes, which pass through.
This simple change buys us a lot. It satisfies my immediate need for a
pseudo-class solution, and it heads us in the right direction, in that
the pseudo-class api doesn't have to change when we implement the full
solution that gives the component developer's more flexibility.
Thanks, Adam!
- Jeanne
Simon Lessard wrote:
> Hello Jeanne,
>
> Yes I'm aware that states can go on the component's sub-part, but are you
> suggesting that we extends the concept to be flexible enough to allow
> thecomponent to intercept a given state on the root element but not on
> the
> sub-part? e.g. inputText would intercept :disabled when placed on
> af|inputText but not on af|inputText::content? That's some complexity but
> it's doable I guess.
>
>
> Regards,
>
> ~Simon
>
> On 8/22/06, Jeanne Waldman <je...@oracle.com> wrote:
>
>>
>> I agree that only the renderers should know what states they want to
>> intercept. I was thinking we add this information in the renderer .xml
>> file and then when we build our classes, we can put this information
>> somewhere -- not sure where.
>>
>> I'm sure you realize this, but just in case... the states do not have to
>> go on the root dom element, they can go on sub-root elements, like
>> af|train::stop:disabled.
>>
>> Simon Lessard wrote:
>>
>> > Hmmm, I'm leaning toward the per component basis option more and more.
>> > However, I hate static lists and additional config files are not all
>> that
>> > great. I see a possibility though. Maybe it will work, but I did not
>> > explore
>> > that area much yet so I might say something stupid. Currently it seem
>> > to me
>> > that skins are linked to the renderkit. So, how feasible would it
>> be to
>> > create a SkinRenderKitFactory that would, before giving away any
>> > renderer,
>> > would populate a Map<component, list<state>> be interrogating all
>> > renderers
>> > in the kit. That way, when StyleSheetRenderer would do its work, we
>> > would be
>> > sure that the list is populated. Also, with that solution, only the
>> > renderers would have to know what states they want to intercept. This
>> > also
>> > fix the synchronization issue, changing the kit or the renderer would
>> > automatically update the interception list. We would have to create a
>> new
>> > BaseRenderer in the API however. I see two additional methods
>> needed for
>> > such renderers:
>> >
>> > public String getComponentName() // or I guess getRootStyleClass would
>> > work
>> > just as well
>> > public List<String> getInterceptedStates(); // Returning the list of
>> > states
>> > to intercept.
>> >
>> >
>> > Makes sense?
>> >
>> > ~ Simon
>> >
>> > On 8/21/06, Jeanne Waldman <je...@oracle.com> wrote:
>> >
>> >>
>> >> More comments inline.
>> >> Which way are you leaning?
>> >>
>> >> - Jeanne
>> >>
>> >> Simon Lessard wrote:
>> >>
>> >> > Hello Jeanne,
>> >> >
>> >> > Thanks for the complete answer.
>> >> >
>> >> > On 8/21/06, Jeanne Waldman <jeanne.waldman@oracle.com > wrote:
>> >> >
>> >> >>
>> >> >> Hi Simon,
>> >> >> Thanks for the email.
>> >> >>
>> >> >> Simon_Lessard@DMR.CA wrote:
>> >> >>
>> >> >> >>We use both syntaxes, and they mean different things.
>> >> >> >>For example:
>> >> >> >>af|train::stop:disabled (when this train's stop is disabled,
>> then
>> >> >> style
>> >> >> >>the stop like this)
>> >> >> >>af|train:disabled::stop (when the entire train is disabled,
>> >> style all
>> >> >> >>the stops like this)
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >Agreed.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >>Let's say I have this: <span class="myText">Hello!</span> and
>> this
>> >> >> css:
>> >> >> >>.myText {color: black}
>> >> >> >>.myText:hover {color:red}
>> >> >> >>Does this work? (not in my tests)
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >It works in Firefox, not IE, as usual. W3C specifies that :hover
>> >> should
>> >> >> >work with everything, but it's not like all browsers will support
>> >> >> >everything W3C says anytime soon. Maybe we should intercept all
>> >> >> >pseudo-classes, if it can be resolved on Java side (like
>> :disabled),
>> >> we
>> >> >> >resolve it there and it never pass through so we prevent all bad
>> >> >> support
>> >> >> >from the browser. For states that cannot be resolved in Java, we
>> >> could
>> >> >> ask
>> >> >> >the Agent if it supports the specified pseudo-class for the
>> >> generated
>> >> >> >element (link:hover works in IE, but not on anything else). If
>> the
>> >> >> agent
>> >> >> >supports it, we let the class pass through to the generated CSS
>> >> >> file, if
>> >> >> >the agent does not, then we could add some JS code to emulate it.
>> >> >> >
>> >> >> >
>> >> >> We generate the css file before we render the components, so when
>> you
>> >> >> say we should intercept all pseudo-classes and if it can be
>> >> resolved on
>> >> >> the Java side, we should resolve it. But how would we know at this
>> >> point
>> >> >> where we are going to render the pseudo-class? that af|foo:hover
>> will
>> >> be
>> >> >> generated on a link? Maybe af|foo:hover is on a <span>, but
>> >> >> af|foo::step:hover is on the link. (we would know if we kept the
>> >> >> skinning-key -> pseudo-class to resolve map). Or do you mean
>> >> literally
>> >> >> that if we can resolve it on the Java side -- even if the browser
>> can
>> >> as
>> >> >> well -- we go ahead and do that?
>> >> >
>> >> >
>> >> >
>> >> > I mean litterally that we make a list of pseudo-classes that we
>> know
>> >> > we can
>> >> > always resolve during rendering, like :disabled, and always
>> intercept
>> >> > it. In
>> >> > a sense it would be a way to cover browsers' lack of support for
>> those
>> >> > pseudo-classes.
>> >> >
>> >> > In the case of :hover, do we pass that through for IE or not? Let's
>> >> say
>> >> >
>> >> >> we don't pass it through for IE. Then we'll need some code that
>> gets
>> >> >> :hover and says, oh, we are on IE, so don't pass this through but
>> >> >> instead do some onmouseover + css magic. This seems like it could
>> get
>> >> >> messy fast.
>> >> >
>> >> >
>> >> >
>> >> > Fair point, the renderers would have to check if there's a selector
>> >> using
>> >> > :hover defined in the current skin and add some JS, it's messy
>> indeed.
>> >> >
>> >> >> The main problem I have the "per component" option is the
>> potential
>> >> >> >performance overhaul it represents as well as the increased
>> >> component
>> >> >> >development complexity (since you have to put more information in
>> >> the
>> >> >> >metadata).
>> >> >> >
>> >> >> >
>> >> >> I don't think of this as a performance hit, since this will happen
>> at
>> >> >> the css generation time, not with every renderer. And we cache the
>> >> >> generated css file.
>> >> >> It would be like the map I have now in FileSystemStyleCache.
>> >> >
>> >> >
>> >> >
>> >> > Small question here. When is the CSS generated exactly? Is it at
>> >> > startup or
>> >> > at the first request for a given skin family? If it is during
>> startup,
>> >> > the
>> >> > performance hit is indeed a non issue.
>> >>
>> >> rendered in StyleSheetRenderer. We get it out of the cache if it is
>> >> there, otherwise we generate it.
>> >>
>> >> >
>> >> > However, we would need to keep the renderer and this map in sync.
>> >> For my
>> >> >
>> >> >> renderer 'foo', I know that I want to handle 'hover' myself, so I
>> put
>> >> >> the hover -> p_AFHover in the map that will be consulted when we
>> >> >> generate the css file. af|foo:hover does not pass through. All
>> other
>> >> >> :hover passes through. I don't think this is that terrible. I like
>> >> this
>> >> >> better than the prefix, because if, down the line, we decide
>> that we
>> >> can
>> >> >> pass through the pseudo-class, the user's skin will not have to
>> >> change,
>> >> >> but our code will get simpler.
>> >> >
>> >> >
>> >> >
>> >> > Not that bad, but I kind of dislike hard coded lists as component
>> >> > developers
>> >> > won't be able to use the skinning feature without giving it to
>> >> Trinidad
>> >> > project since they will have to hack Trinidad's jar file to add
>> their
>> >> own
>> >> > states to the map. If that way is chosen, I would rather use
>> another
>> >> > configuration file or some faces-config meta-data entries. For now
>> >> > skin is
>> >> > not a public API, but I'm prety sure it will become one at some
>> >> point in
>> >> > time.
>> >>
>> >> We definitely need to get it out of FileSystemStyleCache. No doubt
>> about
>> >> it.
>> >>
>> >> >
>> >> >> The prefix is ok, but I find it a bit counter intuitive since the
>> >> >> user has
>> >> >> >to know which states will be handled by browser and which are
>> >> >> managed by
>> >> >> >Trinidad. I would prefer to hide that kind of low level
>> >> implementation
>> >> >> >details to skinners.
>> >> >> >
>> >> >> >
>> >> >> We would definitely document all the -tri- pseudo-classes per
>> >> skinning
>> >> >> key. For example:
>> >> >> af|inputText:-tri-required, af|inputText:-tri-read-only,
>> >> >> af|inputText:-tri-disabled. But for af|train::stop-link,
>> >> >> we'd document that they can use :hover.
>> >> >
>> >> >
>> >> >
>> >> > It works, but it's a bit ugly imho. Furthermore, as you pointed
>> out,
>> >> such
>> >> > solution would force skin CSS changes if we beside to let any given
>> >> state
>> >> > pass through in the future.
>> >>
>> >> true.
>> >>
>> >> >
>> >> >> On a side note that could lead to a new post, what should we do
>> with
>> >> >> >icons? Currently the engine considers a selector an icon one
>> if it
>> >> ends
>> >> >> >with -icon. This lead to some strange selectors sometimes like
>> >> >> >-icon-style-class simply to prevent the parser to interpret it as
>> an
>> >> >> icon.
>> >> >> >Maybe we should add something like :::icon, ::tri-icon or --icon?
>> >> That
>> >> >> way
>> >> >> >there will be no ambiguity left.
>> >> >> >
>> >> >> >
>> >> >> I don't have a problem with saying -icon-style when what you
>> mean is
>> >> >> that you want to style the icon, and ending the key with -icon
>> >> when it
>> >> >> means an icon.
>> >> >
>> >> >
>> >> >
>> >> > It's not that bad, true, but do we have a doc somewhere to document
>> >> this
>> >> > kind of skinning rules? If not, should I add a wiki entry for it
>> even
>> >> > if the
>> >> > API is not public yet? Other things interesting I see are
>> >> FileSystemCache
>> >> > and the mandatory "af" namespace.
>> >>
>> >> We don't have a skinning document for Trinidad developers (as opposed
>> to
>> >> application developers using Trinidad).
>> >> Starting a wiki would be great. I can populate it with some
>> information
>> >> I have.
>> >>
>> >> Yeah, the namespace is purely to make it so that the skinner knows
>> there
>> >> are Trinidad keys.
>> >> We need to change these to tr for one thing. The code might be a
>> little
>> >> bit hardcoded to use 'af', so that will need to change.
>> >> We don't honor the actual namespace in that you can't add
>> @namespace to
>> >> the top of the css file and then be able to use
>> >> whatever prefix you want. That was very low priority when I was doing
>> >> the skinning, and I'm not so sure we'd want to do that
>> >> anyway, becuase what would we do, substitute the namespace for the
>> >> prefix? Then our css would be huge. :) Maybe some day the
>> >> browsers would work with the @namespace, and when that happens we can
>> >> render it out to our css.
>> >>
>> >> >
>> >> > - Jeanne
>> >> >
>> >> >>
>> >> >> >
>> >> >> >Regards
>> >> >> >
>> >> >> >¬ Simon
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >Jeanne Waldman <jeanne.waldman@oracle.com >
>> >> >> >2006-08-18 18:27
>> >> >> >Please respond to adffaces-dev
>> >> >> >
>> >> >> > To: adffaces-dev@incubator.apache.org
>> >> >> > cc:
>> >> >> > Subject: Re: ADFFACES-49
>> >> inputText::content:required or
>> >> >> >inputText:required::content
>> >> >> >
>> >> >> >
>> >> >> >see inline for some random thoughts. :) I'm glad you brought
>> >> this up,
>> >> >> >because I need to come up with a solution soon for our internal
>> >> project
>> >> >> >that we are working on so that our developers can write their
>> >> renderers
>> >> >> >correctly.
>> >> >> >
>> >> >> >Simon_Lessard@DMR.CA wrote:
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >>Hello all,
>> >> >> >>
>> >> >> >>I raised that issue a while back, but now it's a bit more
>> important
>> >> >> since
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >>I'm trying to finalize ADFFACES-49 issue. What selector
>> synthax do
>> >> you
>> >> >> >>prefer for states:
>> >> >> >>1.1. <component>::<subPart>:<state>
>> >> >> >>1.2. <component>:<state>::<subPart>.
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >We use both syntaxes, and they mean different things.
>> >> >> >
>> >> >> >1.1 means this: The subPart of the component is in this state.
>> >> >> >For example:
>> >> >> >af|train::stop:disabled (when this train's stop is disabled, then
>> >> style
>> >> >> >the stop like this)
>> >> >> >af|train:disabled::stop (when the entire train is disabled, style
>> >> all
>> >> >> >the stops like this)
>> >> >> >
>> >> >> >1.2 means this: The component is in this state, and this is the
>> >> >> subpart.
>> >> >> >For example:
>> >> >> >af|inputText:disabled::content (when the af:inputText
>> >> disabled="true",
>> >> >> >then style the content piece like this)
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >>I prefer the former and it's easier to implement. However, we
>> >> already
>> >> >> >>
>> >> >> >>
>> >> >> >have
>> >> >> >
>> >> >> >
>> >> >> >>some :disabled that use the latter synthax.
>> >> >> >>
>> >> >> >>Secondly, there's also the issue raised by Jeanne, how should we
>> >> >> manage
>> >> >> >>which states are intercepted and which should pass through
>> and be
>> >> >> copied
>> >> >> >>in the final CSS:
>> >> >> >>2.1. Use a component specific list, so that :disabled could pass
>> >> >> through
>> >> >>
>> >> >> >>for some components but get intercepted for some others? If that
>> >> >> solution
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >>is selected, how/where should we configure that list, in the
>> >> >> >>faces-config's metadata?
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >I like this one the best because let's say I use :disabled and I
>> >> >> >intercept it and do some funky things with it. Then let's say I
>> >> decide
>> >> >> >that the css spec deals
>> >> >> >with :disabled perfectly fine, and I don't need to intercept it.
>> >> >> >Also, let's say :hover and :active work great on some dom
>> elements,
>> >> but
>> >> >> >do they work for everything?
>> >> >> >Let's say I have this: <span class="myText">Hello!</span> and
>> this
>> >> css:
>> >> >> >.myText {color: black}
>> >> >> >.myText:hover {color:red}
>> >> >> >Does this work? (not in my tests)
>> >> >> >
>> >> >> >But what if this represents a component. I might want them to be
>> >> >> able to
>> >> >> >specify .myText:hover and have it work even if the built-in
>> browser
>> >> >> >support wasn't there.
>> >> >> >So I would want
>> >> >> >af|myComponent:hover to work.
>> >> >> >I'd render this
>> >> >> ><span class="af_myComponent p_AFHover">Hello!</span>
>> >> >> >when they are hovering over my span.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >>2.2. Use a list of pseudo-classes passing through for all
>> >> components.
>> >> >> >>
>> >> >> >>
>> >> >> >Such
>> >> >> >
>> >> >> >
>> >> >> >>list would have to be based on W3C, but as Jeanne observed, such
>> >> list
>> >> >> >>would break our :disabled that we're intercepting currently and
>> >> could
>> >> >> >>
>> >> >> >>
>> >> >> >lead
>> >> >> >
>> >> >> >
>> >> >> >>to som.e problems if more pseudo-classes are added in future
>> >> >> version of
>> >> >> >>CSS.
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >Yes, I'd have to change the name of :disabled. But so far that is
>> >> the
>> >> >> >only css valid pseudo-class that I use to date.
>> >> >> >We have others like :hover (see above... if we don't want this to
>> >> pass
>> >> >> >through, we'll need to change it to something else).
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >>2.3. Use a static list of pseudo-classes to intercept used by
>> all
>> >> >> >>components? If so, where should we place it? This solution
>> probably
>> >> >> has
>> >> >> >>the same flaws as 2.2 if a new pseudo-classes i nthe CSS
>> >> specification
>> >> >> >>matches a name defined in the intercept list.
>> >> >> >>2.4. Use a prefix for intercepted pseudo-classes like the -ora-
>> >> >> used for
>> >> >>
>> >> >> >>properties?
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >I like this second best. If we did this, then I'd suggest that we
>> >> also
>> >> >> >prefix the pseudo-elements.
>> >> >> >The problem is, taking my :hover example, some components
>> might be
>> >> >> >rendered such that the browser
>> >> >> >automatically works with :hover on the generated css, but others
>> >> don't,
>> >> >> >so those that don't have to have
>> >> >> >:-tri-hover ?
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >>My votes are:
>> >> >> >>+1 for 1.1
>> >> >> >>+1 for 2.2, but I would not place states resolvable during
>> >> >> rendering in
>> >> >> >>that list, so that disabled is still intercepted.
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >
>>
>>
>
RE: ADFFACES-49 inputText::content:required or
inputText:required::content
Posted by Pavitra Subramaniam <pa...@oracle.com>.
Hello Jeanne and Simon,
There could be cases where intercepted states for a component or it's sub-part need to be considered together rather than individually. Or in some case it might be too early for even the renderer to provide a valid interceptor-state list at init time. The best time may be at rendering time.
For instance, let's assume that the component sub-part "af|train::stop" can be in the following states :visited and :selected states.
At runtime if the stop is selected, it may be rendered as a span and as an anchor, <a >, if it was visited before (and hence clickable). Both these elements may want to support the :hover pseudo-class.
If I wanted the :hover to pass through if it's for selected stop (for the <span>) and intercept :hover if it's for a stop that is visited (link), would the proposed solution work?
Thanks
- Pavitra
-----Original Message-----
From: Simon Lessard [mailto:simon.lessard.3@gmail.com]
Sent: Wednesday, August 23, 2006 6:28 AM
To: adffaces-dev@incubator.apache.org
Subject: Re: ADFFACES-49 inputText::content:required or inputText:required::content
Hello Jeanne,
Yes I'm aware that states can go on the component's sub-part, but are you suggesting that we extends the concept to be flexible enough to allow thecomponent to intercept a given state on the root element but not on the sub-part? e.g. inputText would intercept :disabled when placed on
af|inputText but not on af|inputText::content? That's some complexity
af|but
it's doable I guess.
Regards,
~Simon
On 8/22/06, Jeanne Waldman <je...@oracle.com> wrote:
>
> I agree that only the renderers should know what states they want to
> intercept. I was thinking we add this information in the renderer .xml
> file and then when we build our classes, we can put this information
> somewhere -- not sure where.
>
> I'm sure you realize this, but just in case... the states do not have
> to go on the root dom element, they can go on sub-root elements, like
> af|train::stop:disabled.
>
> Simon Lessard wrote:
>
> > Hmmm, I'm leaning toward the per component basis option more and more.
> > However, I hate static lists and additional config files are not all
> that
> > great. I see a possibility though. Maybe it will work, but I did not
> > explore that area much yet so I might say something stupid.
> > Currently it seem to me that skins are linked to the renderkit. So,
> > how feasible would it be to create a SkinRenderKitFactory that
> > would, before giving away any renderer, would populate a
> > Map<component, list<state>> be interrogating all renderers in the
> > kit. That way, when StyleSheetRenderer would do its work, we would
> > be sure that the list is populated. Also, with that solution, only
> > the renderers would have to know what states they want to intercept.
> > This also fix the synchronization issue, changing the kit or the
> > renderer would automatically update the interception list. We would
> > have to create a
> new
> > BaseRenderer in the API however. I see two additional methods needed
> > for such renderers:
> >
> > public String getComponentName() // or I guess getRootStyleClass
> > would work just as well public List<String> getInterceptedStates();
> > // Returning the list of states to intercept.
> >
> >
> > Makes sense?
> >
> > ~ Simon
> >
> > On 8/21/06, Jeanne Waldman <je...@oracle.com> wrote:
> >
> >>
> >> More comments inline.
> >> Which way are you leaning?
> >>
> >> - Jeanne
> >>
> >> Simon Lessard wrote:
> >>
> >> > Hello Jeanne,
> >> >
> >> > Thanks for the complete answer.
> >> >
> >> > On 8/21/06, Jeanne Waldman <jeanne.waldman@oracle.com > wrote:
> >> >
> >> >>
> >> >> Hi Simon,
> >> >> Thanks for the email.
> >> >>
> >> >> Simon_Lessard@DMR.CA wrote:
> >> >>
> >> >> >>We use both syntaxes, and they mean different things.
> >> >> >>For example:
> >> >> >>af|train::stop:disabled (when this train's stop is disabled,
> >> >> >>af|then
> >> >> style
> >> >> >>the stop like this)
> >> >> >>af|train:disabled::stop (when the entire train is disabled,
> >> style all
> >> >> >>the stops like this)
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >Agreed.
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >>Let's say I have this: <span class="myText">Hello!</span> and
> >> >> >>this
> >> >> css:
> >> >> >>.myText {color: black}
> >> >> >>.myText:hover {color:red}
> >> >> >>Does this work? (not in my tests)
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >It works in Firefox, not IE, as usual. W3C specifies that
> >> >> >:hover
> >> should
> >> >> >work with everything, but it's not like all browsers will
> >> >> >support everything W3C says anytime soon. Maybe we should
> >> >> >intercept all pseudo-classes, if it can be resolved on Java
> >> >> >side (like
> :disabled),
> >> we
> >> >> >resolve it there and it never pass through so we prevent all
> >> >> >bad
> >> >> support
> >> >> >from the browser. For states that cannot be resolved in Java,
> >> >> >we
> >> could
> >> >> ask
> >> >> >the Agent if it supports the specified pseudo-class for the
> >> generated
> >> >> >element (link:hover works in IE, but not on anything else). If
> >> >> >the
> >> >> agent
> >> >> >supports it, we let the class pass through to the generated CSS
> >> >> file, if
> >> >> >the agent does not, then we could add some JS code to emulate it.
> >> >> >
> >> >> >
> >> >> We generate the css file before we render the components, so
> >> >> when
> you
> >> >> say we should intercept all pseudo-classes and if it can be
> >> resolved on
> >> >> the Java side, we should resolve it. But how would we know at
> >> >> this
> >> point
> >> >> where we are going to render the pseudo-class? that af|foo:hover
> will
> >> be
> >> >> generated on a link? Maybe af|foo:hover is on a <span>, but
> >> >> af|foo::step:hover is on the link. (we would know if we kept the
> >> >> skinning-key -> pseudo-class to resolve map). Or do you mean
> >> literally
> >> >> that if we can resolve it on the Java side -- even if the
> >> >> browser
> can
> >> as
> >> >> well -- we go ahead and do that?
> >> >
> >> >
> >> >
> >> > I mean litterally that we make a list of pseudo-classes that we
> >> > know we can always resolve during rendering, like :disabled, and
> >> > always intercept it. In a sense it would be a way to cover
> >> > browsers' lack of support for
> those
> >> > pseudo-classes.
> >> >
> >> > In the case of :hover, do we pass that through for IE or not?
> >> > Let's
> >> say
> >> >
> >> >> we don't pass it through for IE. Then we'll need some code that
> >> >> gets :hover and says, oh, we are on IE, so don't pass this
> >> >> through but instead do some onmouseover + css magic. This seems
> >> >> like it could
> get
> >> >> messy fast.
> >> >
> >> >
> >> >
> >> > Fair point, the renderers would have to check if there's a
> >> > selector
> >> using
> >> > :hover defined in the current skin and add some JS, it's messy
> indeed.
> >> >
> >> >> The main problem I have the "per component" option is the
> >> >> potential
> >> >> >performance overhaul it represents as well as the increased
> >> component
> >> >> >development complexity (since you have to put more information
> >> >> >in
> >> the
> >> >> >metadata).
> >> >> >
> >> >> >
> >> >> I don't think of this as a performance hit, since this will
> >> >> happen
> at
> >> >> the css generation time, not with every renderer. And we cache
> >> >> the generated css file.
> >> >> It would be like the map I have now in FileSystemStyleCache.
> >> >
> >> >
> >> >
> >> > Small question here. When is the CSS generated exactly? Is it at
> >> > startup or at the first request for a given skin family? If it is
> >> > during
> startup,
> >> > the
> >> > performance hit is indeed a non issue.
> >>
> >> rendered in StyleSheetRenderer. We get it out of the cache if it is
> >> there, otherwise we generate it.
> >>
> >> >
> >> > However, we would need to keep the renderer and this map in sync.
> >> For my
> >> >
> >> >> renderer 'foo', I know that I want to handle 'hover' myself, so
> >> >> I
> put
> >> >> the hover -> p_AFHover in the map that will be consulted when we
> >> >> generate the css file. af|foo:hover does not pass through. All
> >> >> other :hover passes through. I don't think this is that
> >> >> terrible. I like
> >> this
> >> >> better than the prefix, because if, down the line, we decide
> >> >> that we
> >> can
> >> >> pass through the pseudo-class, the user's skin will not have to
> >> change,
> >> >> but our code will get simpler.
> >> >
> >> >
> >> >
> >> > Not that bad, but I kind of dislike hard coded lists as component
> >> > developers won't be able to use the skinning feature without
> >> > giving it to
> >> Trinidad
> >> > project since they will have to hack Trinidad's jar file to add
> >> > their
> >> own
> >> > states to the map. If that way is chosen, I would rather use
> >> > another configuration file or some faces-config meta-data
> >> > entries. For now skin is not a public API, but I'm prety sure it
> >> > will become one at some
> >> point in
> >> > time.
> >>
> >> We definitely need to get it out of FileSystemStyleCache. No doubt
> about
> >> it.
> >>
> >> >
> >> >> The prefix is ok, but I find it a bit counter intuitive since
> >> >> the user has
> >> >> >to know which states will be handled by browser and which are
> >> >> managed by
> >> >> >Trinidad. I would prefer to hide that kind of low level
> >> implementation
> >> >> >details to skinners.
> >> >> >
> >> >> >
> >> >> We would definitely document all the -tri- pseudo-classes per
> >> skinning
> >> >> key. For example:
> >> >> af|inputText:-tri-required, af|inputText:-tri-read-only,
> >> >> af|inputText:-tri-disabled. But for af|train::stop-link,
> >> >> we'd document that they can use :hover.
> >> >
> >> >
> >> >
> >> > It works, but it's a bit ugly imho. Furthermore, as you pointed
> >> > out,
> >> such
> >> > solution would force skin CSS changes if we beside to let any
> >> > given
> >> state
> >> > pass through in the future.
> >>
> >> true.
> >>
> >> >
> >> >> On a side note that could lead to a new post, what should we do
> >> >> with
> >> >> >icons? Currently the engine considers a selector an icon one if
> >> >> >it
> >> ends
> >> >> >with -icon. This lead to some strange selectors sometimes like
> >> >> >-icon-style-class simply to prevent the parser to interpret it
> >> >> >as
> an
> >> >> icon.
> >> >> >Maybe we should add something like :::icon, ::tri-icon or --icon?
> >> That
> >> >> way
> >> >> >there will be no ambiguity left.
> >> >> >
> >> >> >
> >> >> I don't have a problem with saying -icon-style when what you
> >> >> mean is that you want to style the icon, and ending the key with
> >> >> -icon
> >> when it
> >> >> means an icon.
> >> >
> >> >
> >> >
> >> > It's not that bad, true, but do we have a doc somewhere to
> >> > document
> >> this
> >> > kind of skinning rules? If not, should I add a wiki entry for it
> >> > even if the API is not public yet? Other things interesting I see
> >> > are
> >> FileSystemCache
> >> > and the mandatory "af" namespace.
> >>
> >> We don't have a skinning document for Trinidad developers (as
> >> opposed
> to
> >> application developers using Trinidad).
> >> Starting a wiki would be great. I can populate it with some
> >> information I have.
> >>
> >> Yeah, the namespace is purely to make it so that the skinner knows
> there
> >> are Trinidad keys.
> >> We need to change these to tr for one thing. The code might be a
> >> little bit hardcoded to use 'af', so that will need to change.
> >> We don't honor the actual namespace in that you can't add
> >> @namespace to the top of the css file and then be able to use
> >> whatever prefix you want. That was very low priority when I was
> >> doing the skinning, and I'm not so sure we'd want to do that
> >> anyway, becuase what would we do, substitute the namespace for the
> >> prefix? Then our css would be huge. :) Maybe some day the browsers
> >> would work with the @namespace, and when that happens we can render
> >> it out to our css.
> >>
> >> >
> >> > - Jeanne
> >> >
> >> >>
> >> >> >
> >> >> >Regards
> >> >> >
> >> >> >¬ Simon
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >Jeanne Waldman <jeanne.waldman@oracle.com >
> >> >> >2006-08-18 18:27
> >> >> >Please respond to adffaces-dev
> >> >> >
> >> >> > To: adffaces-dev@incubator.apache.org
> >> >> > cc:
> >> >> > Subject: Re: ADFFACES-49
> >> inputText::content:required or
> >> >> >inputText:required::content
> >> >> >
> >> >> >
> >> >> >see inline for some random thoughts. :) I'm glad you brought
> >> this up,
> >> >> >because I need to come up with a solution soon for our internal
> >> project
> >> >> >that we are working on so that our developers can write their
> >> renderers
> >> >> >correctly.
> >> >> >
> >> >> >Simon_Lessard@DMR.CA wrote:
> >> >> >
> >> >> >
> >> >> >
> >> >> >>Hello all,
> >> >> >>
> >> >> >>I raised that issue a while back, but now it's a bit more
> important
> >> >> since
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> >>I'm trying to finalize ADFFACES-49 issue. What selector
> >> >> >>synthax do
> >> you
> >> >> >>prefer for states:
> >> >> >>1.1. <component>::<subPart>:<state> 1.2.
> >> >> >><component>:<state>::<subPart>.
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >We use both syntaxes, and they mean different things.
> >> >> >
> >> >> >1.1 means this: The subPart of the component is in this state.
> >> >> >For example:
> >> >> >af|train::stop:disabled (when this train's stop is disabled,
> >> >> >af|then
> >> style
> >> >> >the stop like this)
> >> >> >af|train:disabled::stop (when the entire train is disabled,
> >> >> >af|style
> >> all
> >> >> >the stops like this)
> >> >> >
> >> >> >1.2 means this: The component is in this state, and this is the
> >> >> subpart.
> >> >> >For example:
> >> >> >af|inputText:disabled::content (when the af:inputText
> >> disabled="true",
> >> >> >then style the content piece like this)
> >> >> >
> >> >> >
> >> >> >
> >> >> >>I prefer the former and it's easier to implement. However, we
> >> already
> >> >> >>
> >> >> >>
> >> >> >have
> >> >> >
> >> >> >
> >> >> >>some :disabled that use the latter synthax.
> >> >> >>
> >> >> >>Secondly, there's also the issue raised by Jeanne, how should
> >> >> >>we
> >> >> manage
> >> >> >>which states are intercepted and which should pass through and
> >> >> >>be
> >> >> copied
> >> >> >>in the final CSS:
> >> >> >>2.1. Use a component specific list, so that :disabled could
> >> >> >>pass
> >> >> through
> >> >>
> >> >> >>for some components but get intercepted for some others? If
> >> >> >>that
> >> >> solution
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> >>is selected, how/where should we configure that list, in the
> >> >> >>faces-config's metadata?
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >I like this one the best because let's say I use :disabled and
> >> >> >I intercept it and do some funky things with it. Then let's say
> >> >> >I
> >> decide
> >> >> >that the css spec deals
> >> >> >with :disabled perfectly fine, and I don't need to intercept it.
> >> >> >Also, let's say :hover and :active work great on some dom
> >> >> >elements,
> >> but
> >> >> >do they work for everything?
> >> >> >Let's say I have this: <span class="myText">Hello!</span> and
> >> >> >this
> >> css:
> >> >> >.myText {color: black}
> >> >> >.myText:hover {color:red}
> >> >> >Does this work? (not in my tests)
> >> >> >
> >> >> >But what if this represents a component. I might want them to
> >> >> >be
> >> >> able to
> >> >> >specify .myText:hover and have it work even if the built-in
> >> >> >browser support wasn't there.
> >> >> >So I would want
> >> >> >af|myComponent:hover to work.
> >> >> >I'd render this
> >> >> ><span class="af_myComponent p_AFHover">Hello!</span> when they
> >> >> >are hovering over my span.
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >>2.2. Use a list of pseudo-classes passing through for all
> >> components.
> >> >> >>
> >> >> >>
> >> >> >Such
> >> >> >
> >> >> >
> >> >> >>list would have to be based on W3C, but as Jeanne observed,
> >> >> >>such
> >> list
> >> >> >>would break our :disabled that we're intercepting currently
> >> >> >>and
> >> could
> >> >> >>
> >> >> >>
> >> >> >lead
> >> >> >
> >> >> >
> >> >> >>to som.e problems if more pseudo-classes are added in future
> >> >> version of
> >> >> >>CSS.
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >Yes, I'd have to change the name of :disabled. But so far that
> >> >> >is
> >> the
> >> >> >only css valid pseudo-class that I use to date.
> >> >> >We have others like :hover (see above... if we don't want this
> >> >> >to
> >> pass
> >> >> >through, we'll need to change it to something else).
> >> >> >
> >> >> >
> >> >> >
> >> >> >>2.3. Use a static list of pseudo-classes to intercept used by
> >> >> >>all components? If so, where should we place it? This solution
> probably
> >> >> has
> >> >> >>the same flaws as 2.2 if a new pseudo-classes i nthe CSS
> >> specification
> >> >> >>matches a name defined in the intercept list.
> >> >> >>2.4. Use a prefix for intercepted pseudo-classes like the
> >> >> >>-ora-
> >> >> used for
> >> >>
> >> >> >>properties?
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >I like this second best. If we did this, then I'd suggest that
> >> >> >we
> >> also
> >> >> >prefix the pseudo-elements.
> >> >> >The problem is, taking my :hover example, some components might
> >> >> >be rendered such that the browser automatically works with
> >> >> >:hover on the generated css, but others
> >> don't,
> >> >> >so those that don't have to have :-tri-hover ?
> >> >> >
> >> >> >
> >> >> >
> >> >> >>My votes are:
> >> >> >>+1 for 1.1
> >> >> >>+1 for 2.2, but I would not place states resolvable during
> >> >> rendering in
> >> >> >>that list, so that disabled is still intercepted.
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >
> >>
> >>
> >
>
>
Re: ADFFACES-49 inputText::content:required or inputText:required::content
Posted by Simon Lessard <si...@gmail.com>.
Hello Jeanne,
Yes I'm aware that states can go on the component's sub-part, but are you
suggesting that we extends the concept to be flexible enough to allow
thecomponent to intercept a given state on the root element but not on the
sub-part? e.g. inputText would intercept :disabled when placed on
af|inputText but not on af|inputText::content? That's some complexity but
it's doable I guess.
Regards,
~Simon
On 8/22/06, Jeanne Waldman <je...@oracle.com> wrote:
>
> I agree that only the renderers should know what states they want to
> intercept. I was thinking we add this information in the renderer .xml
> file and then when we build our classes, we can put this information
> somewhere -- not sure where.
>
> I'm sure you realize this, but just in case... the states do not have to
> go on the root dom element, they can go on sub-root elements, like
> af|train::stop:disabled.
>
> Simon Lessard wrote:
>
> > Hmmm, I'm leaning toward the per component basis option more and more.
> > However, I hate static lists and additional config files are not all
> that
> > great. I see a possibility though. Maybe it will work, but I did not
> > explore
> > that area much yet so I might say something stupid. Currently it seem
> > to me
> > that skins are linked to the renderkit. So, how feasible would it be to
> > create a SkinRenderKitFactory that would, before giving away any
> > renderer,
> > would populate a Map<component, list<state>> be interrogating all
> > renderers
> > in the kit. That way, when StyleSheetRenderer would do its work, we
> > would be
> > sure that the list is populated. Also, with that solution, only the
> > renderers would have to know what states they want to intercept. This
> > also
> > fix the synchronization issue, changing the kit or the renderer would
> > automatically update the interception list. We would have to create a
> new
> > BaseRenderer in the API however. I see two additional methods needed for
> > such renderers:
> >
> > public String getComponentName() // or I guess getRootStyleClass would
> > work
> > just as well
> > public List<String> getInterceptedStates(); // Returning the list of
> > states
> > to intercept.
> >
> >
> > Makes sense?
> >
> > ~ Simon
> >
> > On 8/21/06, Jeanne Waldman <je...@oracle.com> wrote:
> >
> >>
> >> More comments inline.
> >> Which way are you leaning?
> >>
> >> - Jeanne
> >>
> >> Simon Lessard wrote:
> >>
> >> > Hello Jeanne,
> >> >
> >> > Thanks for the complete answer.
> >> >
> >> > On 8/21/06, Jeanne Waldman <jeanne.waldman@oracle.com > wrote:
> >> >
> >> >>
> >> >> Hi Simon,
> >> >> Thanks for the email.
> >> >>
> >> >> Simon_Lessard@DMR.CA wrote:
> >> >>
> >> >> >>We use both syntaxes, and they mean different things.
> >> >> >>For example:
> >> >> >>af|train::stop:disabled (when this train's stop is disabled, then
> >> >> style
> >> >> >>the stop like this)
> >> >> >>af|train:disabled::stop (when the entire train is disabled,
> >> style all
> >> >> >>the stops like this)
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >Agreed.
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >>Let's say I have this: <span class="myText">Hello!</span> and this
> >> >> css:
> >> >> >>.myText {color: black}
> >> >> >>.myText:hover {color:red}
> >> >> >>Does this work? (not in my tests)
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >It works in Firefox, not IE, as usual. W3C specifies that :hover
> >> should
> >> >> >work with everything, but it's not like all browsers will support
> >> >> >everything W3C says anytime soon. Maybe we should intercept all
> >> >> >pseudo-classes, if it can be resolved on Java side (like
> :disabled),
> >> we
> >> >> >resolve it there and it never pass through so we prevent all bad
> >> >> support
> >> >> >from the browser. For states that cannot be resolved in Java, we
> >> could
> >> >> ask
> >> >> >the Agent if it supports the specified pseudo-class for the
> >> generated
> >> >> >element (link:hover works in IE, but not on anything else). If the
> >> >> agent
> >> >> >supports it, we let the class pass through to the generated CSS
> >> >> file, if
> >> >> >the agent does not, then we could add some JS code to emulate it.
> >> >> >
> >> >> >
> >> >> We generate the css file before we render the components, so when
> you
> >> >> say we should intercept all pseudo-classes and if it can be
> >> resolved on
> >> >> the Java side, we should resolve it. But how would we know at this
> >> point
> >> >> where we are going to render the pseudo-class? that af|foo:hover
> will
> >> be
> >> >> generated on a link? Maybe af|foo:hover is on a <span>, but
> >> >> af|foo::step:hover is on the link. (we would know if we kept the
> >> >> skinning-key -> pseudo-class to resolve map). Or do you mean
> >> literally
> >> >> that if we can resolve it on the Java side -- even if the browser
> can
> >> as
> >> >> well -- we go ahead and do that?
> >> >
> >> >
> >> >
> >> > I mean litterally that we make a list of pseudo-classes that we know
> >> > we can
> >> > always resolve during rendering, like :disabled, and always intercept
> >> > it. In
> >> > a sense it would be a way to cover browsers' lack of support for
> those
> >> > pseudo-classes.
> >> >
> >> > In the case of :hover, do we pass that through for IE or not? Let's
> >> say
> >> >
> >> >> we don't pass it through for IE. Then we'll need some code that gets
> >> >> :hover and says, oh, we are on IE, so don't pass this through but
> >> >> instead do some onmouseover + css magic. This seems like it could
> get
> >> >> messy fast.
> >> >
> >> >
> >> >
> >> > Fair point, the renderers would have to check if there's a selector
> >> using
> >> > :hover defined in the current skin and add some JS, it's messy
> indeed.
> >> >
> >> >> The main problem I have the "per component" option is the potential
> >> >> >performance overhaul it represents as well as the increased
> >> component
> >> >> >development complexity (since you have to put more information in
> >> the
> >> >> >metadata).
> >> >> >
> >> >> >
> >> >> I don't think of this as a performance hit, since this will happen
> at
> >> >> the css generation time, not with every renderer. And we cache the
> >> >> generated css file.
> >> >> It would be like the map I have now in FileSystemStyleCache.
> >> >
> >> >
> >> >
> >> > Small question here. When is the CSS generated exactly? Is it at
> >> > startup or
> >> > at the first request for a given skin family? If it is during
> startup,
> >> > the
> >> > performance hit is indeed a non issue.
> >>
> >> rendered in StyleSheetRenderer. We get it out of the cache if it is
> >> there, otherwise we generate it.
> >>
> >> >
> >> > However, we would need to keep the renderer and this map in sync.
> >> For my
> >> >
> >> >> renderer 'foo', I know that I want to handle 'hover' myself, so I
> put
> >> >> the hover -> p_AFHover in the map that will be consulted when we
> >> >> generate the css file. af|foo:hover does not pass through. All other
> >> >> :hover passes through. I don't think this is that terrible. I like
> >> this
> >> >> better than the prefix, because if, down the line, we decide that we
> >> can
> >> >> pass through the pseudo-class, the user's skin will not have to
> >> change,
> >> >> but our code will get simpler.
> >> >
> >> >
> >> >
> >> > Not that bad, but I kind of dislike hard coded lists as component
> >> > developers
> >> > won't be able to use the skinning feature without giving it to
> >> Trinidad
> >> > project since they will have to hack Trinidad's jar file to add their
> >> own
> >> > states to the map. If that way is chosen, I would rather use another
> >> > configuration file or some faces-config meta-data entries. For now
> >> > skin is
> >> > not a public API, but I'm prety sure it will become one at some
> >> point in
> >> > time.
> >>
> >> We definitely need to get it out of FileSystemStyleCache. No doubt
> about
> >> it.
> >>
> >> >
> >> >> The prefix is ok, but I find it a bit counter intuitive since the
> >> >> user has
> >> >> >to know which states will be handled by browser and which are
> >> >> managed by
> >> >> >Trinidad. I would prefer to hide that kind of low level
> >> implementation
> >> >> >details to skinners.
> >> >> >
> >> >> >
> >> >> We would definitely document all the -tri- pseudo-classes per
> >> skinning
> >> >> key. For example:
> >> >> af|inputText:-tri-required, af|inputText:-tri-read-only,
> >> >> af|inputText:-tri-disabled. But for af|train::stop-link,
> >> >> we'd document that they can use :hover.
> >> >
> >> >
> >> >
> >> > It works, but it's a bit ugly imho. Furthermore, as you pointed out,
> >> such
> >> > solution would force skin CSS changes if we beside to let any given
> >> state
> >> > pass through in the future.
> >>
> >> true.
> >>
> >> >
> >> >> On a side note that could lead to a new post, what should we do with
> >> >> >icons? Currently the engine considers a selector an icon one if it
> >> ends
> >> >> >with -icon. This lead to some strange selectors sometimes like
> >> >> >-icon-style-class simply to prevent the parser to interpret it as
> an
> >> >> icon.
> >> >> >Maybe we should add something like :::icon, ::tri-icon or --icon?
> >> That
> >> >> way
> >> >> >there will be no ambiguity left.
> >> >> >
> >> >> >
> >> >> I don't have a problem with saying -icon-style when what you mean is
> >> >> that you want to style the icon, and ending the key with -icon
> >> when it
> >> >> means an icon.
> >> >
> >> >
> >> >
> >> > It's not that bad, true, but do we have a doc somewhere to document
> >> this
> >> > kind of skinning rules? If not, should I add a wiki entry for it even
> >> > if the
> >> > API is not public yet? Other things interesting I see are
> >> FileSystemCache
> >> > and the mandatory "af" namespace.
> >>
> >> We don't have a skinning document for Trinidad developers (as opposed
> to
> >> application developers using Trinidad).
> >> Starting a wiki would be great. I can populate it with some information
> >> I have.
> >>
> >> Yeah, the namespace is purely to make it so that the skinner knows
> there
> >> are Trinidad keys.
> >> We need to change these to tr for one thing. The code might be a little
> >> bit hardcoded to use 'af', so that will need to change.
> >> We don't honor the actual namespace in that you can't add @namespace to
> >> the top of the css file and then be able to use
> >> whatever prefix you want. That was very low priority when I was doing
> >> the skinning, and I'm not so sure we'd want to do that
> >> anyway, becuase what would we do, substitute the namespace for the
> >> prefix? Then our css would be huge. :) Maybe some day the
> >> browsers would work with the @namespace, and when that happens we can
> >> render it out to our css.
> >>
> >> >
> >> > - Jeanne
> >> >
> >> >>
> >> >> >
> >> >> >Regards
> >> >> >
> >> >> >¬ Simon
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >Jeanne Waldman <jeanne.waldman@oracle.com >
> >> >> >2006-08-18 18:27
> >> >> >Please respond to adffaces-dev
> >> >> >
> >> >> > To: adffaces-dev@incubator.apache.org
> >> >> > cc:
> >> >> > Subject: Re: ADFFACES-49
> >> inputText::content:required or
> >> >> >inputText:required::content
> >> >> >
> >> >> >
> >> >> >see inline for some random thoughts. :) I'm glad you brought
> >> this up,
> >> >> >because I need to come up with a solution soon for our internal
> >> project
> >> >> >that we are working on so that our developers can write their
> >> renderers
> >> >> >correctly.
> >> >> >
> >> >> >Simon_Lessard@DMR.CA wrote:
> >> >> >
> >> >> >
> >> >> >
> >> >> >>Hello all,
> >> >> >>
> >> >> >>I raised that issue a while back, but now it's a bit more
> important
> >> >> since
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> >>I'm trying to finalize ADFFACES-49 issue. What selector synthax do
> >> you
> >> >> >>prefer for states:
> >> >> >>1.1. <component>::<subPart>:<state>
> >> >> >>1.2. <component>:<state>::<subPart>.
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >We use both syntaxes, and they mean different things.
> >> >> >
> >> >> >1.1 means this: The subPart of the component is in this state.
> >> >> >For example:
> >> >> >af|train::stop:disabled (when this train's stop is disabled, then
> >> style
> >> >> >the stop like this)
> >> >> >af|train:disabled::stop (when the entire train is disabled, style
> >> all
> >> >> >the stops like this)
> >> >> >
> >> >> >1.2 means this: The component is in this state, and this is the
> >> >> subpart.
> >> >> >For example:
> >> >> >af|inputText:disabled::content (when the af:inputText
> >> disabled="true",
> >> >> >then style the content piece like this)
> >> >> >
> >> >> >
> >> >> >
> >> >> >>I prefer the former and it's easier to implement. However, we
> >> already
> >> >> >>
> >> >> >>
> >> >> >have
> >> >> >
> >> >> >
> >> >> >>some :disabled that use the latter synthax.
> >> >> >>
> >> >> >>Secondly, there's also the issue raised by Jeanne, how should we
> >> >> manage
> >> >> >>which states are intercepted and which should pass through and be
> >> >> copied
> >> >> >>in the final CSS:
> >> >> >>2.1. Use a component specific list, so that :disabled could pass
> >> >> through
> >> >>
> >> >> >>for some components but get intercepted for some others? If that
> >> >> solution
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> >>is selected, how/where should we configure that list, in the
> >> >> >>faces-config's metadata?
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >I like this one the best because let's say I use :disabled and I
> >> >> >intercept it and do some funky things with it. Then let's say I
> >> decide
> >> >> >that the css spec deals
> >> >> >with :disabled perfectly fine, and I don't need to intercept it.
> >> >> >Also, let's say :hover and :active work great on some dom elements,
> >> but
> >> >> >do they work for everything?
> >> >> >Let's say I have this: <span class="myText">Hello!</span> and this
> >> css:
> >> >> >.myText {color: black}
> >> >> >.myText:hover {color:red}
> >> >> >Does this work? (not in my tests)
> >> >> >
> >> >> >But what if this represents a component. I might want them to be
> >> >> able to
> >> >> >specify .myText:hover and have it work even if the built-in browser
> >> >> >support wasn't there.
> >> >> >So I would want
> >> >> >af|myComponent:hover to work.
> >> >> >I'd render this
> >> >> ><span class="af_myComponent p_AFHover">Hello!</span>
> >> >> >when they are hovering over my span.
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >>2.2. Use a list of pseudo-classes passing through for all
> >> components.
> >> >> >>
> >> >> >>
> >> >> >Such
> >> >> >
> >> >> >
> >> >> >>list would have to be based on W3C, but as Jeanne observed, such
> >> list
> >> >> >>would break our :disabled that we're intercepting currently and
> >> could
> >> >> >>
> >> >> >>
> >> >> >lead
> >> >> >
> >> >> >
> >> >> >>to som.e problems if more pseudo-classes are added in future
> >> >> version of
> >> >> >>CSS.
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >Yes, I'd have to change the name of :disabled. But so far that is
> >> the
> >> >> >only css valid pseudo-class that I use to date.
> >> >> >We have others like :hover (see above... if we don't want this to
> >> pass
> >> >> >through, we'll need to change it to something else).
> >> >> >
> >> >> >
> >> >> >
> >> >> >>2.3. Use a static list of pseudo-classes to intercept used by all
> >> >> >>components? If so, where should we place it? This solution
> probably
> >> >> has
> >> >> >>the same flaws as 2.2 if a new pseudo-classes i nthe CSS
> >> specification
> >> >> >>matches a name defined in the intercept list.
> >> >> >>2.4. Use a prefix for intercepted pseudo-classes like the -ora-
> >> >> used for
> >> >>
> >> >> >>properties?
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >I like this second best. If we did this, then I'd suggest that we
> >> also
> >> >> >prefix the pseudo-elements.
> >> >> >The problem is, taking my :hover example, some components might be
> >> >> >rendered such that the browser
> >> >> >automatically works with :hover on the generated css, but others
> >> don't,
> >> >> >so those that don't have to have
> >> >> >:-tri-hover ?
> >> >> >
> >> >> >
> >> >> >
> >> >> >>My votes are:
> >> >> >>+1 for 1.1
> >> >> >>+1 for 2.2, but I would not place states resolvable during
> >> >> rendering in
> >> >> >>that list, so that disabled is still intercepted.
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >
> >>
> >>
> >
>
>
Re: ADFFACES-49 inputText::content:required or inputText:required::content
Posted by Jeanne Waldman <je...@oracle.com>.
I agree that only the renderers should know what states they want to
intercept. I was thinking we add this information in the renderer .xml
file and then when we build our classes, we can put this information
somewhere -- not sure where.
I'm sure you realize this, but just in case... the states do not have to
go on the root dom element, they can go on sub-root elements, like
af|train::stop:disabled.
Simon Lessard wrote:
> Hmmm, I'm leaning toward the per component basis option more and more.
> However, I hate static lists and additional config files are not all that
> great. I see a possibility though. Maybe it will work, but I did not
> explore
> that area much yet so I might say something stupid. Currently it seem
> to me
> that skins are linked to the renderkit. So, how feasible would it be to
> create a SkinRenderKitFactory that would, before giving away any
> renderer,
> would populate a Map<component, list<state>> be interrogating all
> renderers
> in the kit. That way, when StyleSheetRenderer would do its work, we
> would be
> sure that the list is populated. Also, with that solution, only the
> renderers would have to know what states they want to intercept. This
> also
> fix the synchronization issue, changing the kit or the renderer would
> automatically update the interception list. We would have to create a new
> BaseRenderer in the API however. I see two additional methods needed for
> such renderers:
>
> public String getComponentName() // or I guess getRootStyleClass would
> work
> just as well
> public List<String> getInterceptedStates(); // Returning the list of
> states
> to intercept.
>
>
> Makes sense?
>
> ~ Simon
>
> On 8/21/06, Jeanne Waldman <je...@oracle.com> wrote:
>
>>
>> More comments inline.
>> Which way are you leaning?
>>
>> - Jeanne
>>
>> Simon Lessard wrote:
>>
>> > Hello Jeanne,
>> >
>> > Thanks for the complete answer.
>> >
>> > On 8/21/06, Jeanne Waldman <jeanne.waldman@oracle.com > wrote:
>> >
>> >>
>> >> Hi Simon,
>> >> Thanks for the email.
>> >>
>> >> Simon_Lessard@DMR.CA wrote:
>> >>
>> >> >>We use both syntaxes, and they mean different things.
>> >> >>For example:
>> >> >>af|train::stop:disabled (when this train's stop is disabled, then
>> >> style
>> >> >>the stop like this)
>> >> >>af|train:disabled::stop (when the entire train is disabled,
>> style all
>> >> >>the stops like this)
>> >> >>
>> >> >>
>> >> >
>> >> >Agreed.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >>Let's say I have this: <span class="myText">Hello!</span> and this
>> >> css:
>> >> >>.myText {color: black}
>> >> >>.myText:hover {color:red}
>> >> >>Does this work? (not in my tests)
>> >> >>
>> >> >>
>> >> >
>> >> >It works in Firefox, not IE, as usual. W3C specifies that :hover
>> should
>> >> >work with everything, but it's not like all browsers will support
>> >> >everything W3C says anytime soon. Maybe we should intercept all
>> >> >pseudo-classes, if it can be resolved on Java side (like :disabled),
>> we
>> >> >resolve it there and it never pass through so we prevent all bad
>> >> support
>> >> >from the browser. For states that cannot be resolved in Java, we
>> could
>> >> ask
>> >> >the Agent if it supports the specified pseudo-class for the
>> generated
>> >> >element (link:hover works in IE, but not on anything else). If the
>> >> agent
>> >> >supports it, we let the class pass through to the generated CSS
>> >> file, if
>> >> >the agent does not, then we could add some JS code to emulate it.
>> >> >
>> >> >
>> >> We generate the css file before we render the components, so when you
>> >> say we should intercept all pseudo-classes and if it can be
>> resolved on
>> >> the Java side, we should resolve it. But how would we know at this
>> point
>> >> where we are going to render the pseudo-class? that af|foo:hover will
>> be
>> >> generated on a link? Maybe af|foo:hover is on a <span>, but
>> >> af|foo::step:hover is on the link. (we would know if we kept the
>> >> skinning-key -> pseudo-class to resolve map). Or do you mean
>> literally
>> >> that if we can resolve it on the Java side -- even if the browser can
>> as
>> >> well -- we go ahead and do that?
>> >
>> >
>> >
>> > I mean litterally that we make a list of pseudo-classes that we know
>> > we can
>> > always resolve during rendering, like :disabled, and always intercept
>> > it. In
>> > a sense it would be a way to cover browsers' lack of support for those
>> > pseudo-classes.
>> >
>> > In the case of :hover, do we pass that through for IE or not? Let's
>> say
>> >
>> >> we don't pass it through for IE. Then we'll need some code that gets
>> >> :hover and says, oh, we are on IE, so don't pass this through but
>> >> instead do some onmouseover + css magic. This seems like it could get
>> >> messy fast.
>> >
>> >
>> >
>> > Fair point, the renderers would have to check if there's a selector
>> using
>> > :hover defined in the current skin and add some JS, it's messy indeed.
>> >
>> >> The main problem I have the "per component" option is the potential
>> >> >performance overhaul it represents as well as the increased
>> component
>> >> >development complexity (since you have to put more information in
>> the
>> >> >metadata).
>> >> >
>> >> >
>> >> I don't think of this as a performance hit, since this will happen at
>> >> the css generation time, not with every renderer. And we cache the
>> >> generated css file.
>> >> It would be like the map I have now in FileSystemStyleCache.
>> >
>> >
>> >
>> > Small question here. When is the CSS generated exactly? Is it at
>> > startup or
>> > at the first request for a given skin family? If it is during startup,
>> > the
>> > performance hit is indeed a non issue.
>>
>> rendered in StyleSheetRenderer. We get it out of the cache if it is
>> there, otherwise we generate it.
>>
>> >
>> > However, we would need to keep the renderer and this map in sync.
>> For my
>> >
>> >> renderer 'foo', I know that I want to handle 'hover' myself, so I put
>> >> the hover -> p_AFHover in the map that will be consulted when we
>> >> generate the css file. af|foo:hover does not pass through. All other
>> >> :hover passes through. I don't think this is that terrible. I like
>> this
>> >> better than the prefix, because if, down the line, we decide that we
>> can
>> >> pass through the pseudo-class, the user's skin will not have to
>> change,
>> >> but our code will get simpler.
>> >
>> >
>> >
>> > Not that bad, but I kind of dislike hard coded lists as component
>> > developers
>> > won't be able to use the skinning feature without giving it to
>> Trinidad
>> > project since they will have to hack Trinidad's jar file to add their
>> own
>> > states to the map. If that way is chosen, I would rather use another
>> > configuration file or some faces-config meta-data entries. For now
>> > skin is
>> > not a public API, but I'm prety sure it will become one at some
>> point in
>> > time.
>>
>> We definitely need to get it out of FileSystemStyleCache. No doubt about
>> it.
>>
>> >
>> >> The prefix is ok, but I find it a bit counter intuitive since the
>> >> user has
>> >> >to know which states will be handled by browser and which are
>> >> managed by
>> >> >Trinidad. I would prefer to hide that kind of low level
>> implementation
>> >> >details to skinners.
>> >> >
>> >> >
>> >> We would definitely document all the -tri- pseudo-classes per
>> skinning
>> >> key. For example:
>> >> af|inputText:-tri-required, af|inputText:-tri-read-only,
>> >> af|inputText:-tri-disabled. But for af|train::stop-link,
>> >> we'd document that they can use :hover.
>> >
>> >
>> >
>> > It works, but it's a bit ugly imho. Furthermore, as you pointed out,
>> such
>> > solution would force skin CSS changes if we beside to let any given
>> state
>> > pass through in the future.
>>
>> true.
>>
>> >
>> >> On a side note that could lead to a new post, what should we do with
>> >> >icons? Currently the engine considers a selector an icon one if it
>> ends
>> >> >with -icon. This lead to some strange selectors sometimes like
>> >> >-icon-style-class simply to prevent the parser to interpret it as an
>> >> icon.
>> >> >Maybe we should add something like :::icon, ::tri-icon or --icon?
>> That
>> >> way
>> >> >there will be no ambiguity left.
>> >> >
>> >> >
>> >> I don't have a problem with saying -icon-style when what you mean is
>> >> that you want to style the icon, and ending the key with -icon
>> when it
>> >> means an icon.
>> >
>> >
>> >
>> > It's not that bad, true, but do we have a doc somewhere to document
>> this
>> > kind of skinning rules? If not, should I add a wiki entry for it even
>> > if the
>> > API is not public yet? Other things interesting I see are
>> FileSystemCache
>> > and the mandatory "af" namespace.
>>
>> We don't have a skinning document for Trinidad developers (as opposed to
>> application developers using Trinidad).
>> Starting a wiki would be great. I can populate it with some information
>> I have.
>>
>> Yeah, the namespace is purely to make it so that the skinner knows there
>> are Trinidad keys.
>> We need to change these to tr for one thing. The code might be a little
>> bit hardcoded to use 'af', so that will need to change.
>> We don't honor the actual namespace in that you can't add @namespace to
>> the top of the css file and then be able to use
>> whatever prefix you want. That was very low priority when I was doing
>> the skinning, and I'm not so sure we'd want to do that
>> anyway, becuase what would we do, substitute the namespace for the
>> prefix? Then our css would be huge. :) Maybe some day the
>> browsers would work with the @namespace, and when that happens we can
>> render it out to our css.
>>
>> >
>> > - Jeanne
>> >
>> >>
>> >> >
>> >> >Regards
>> >> >
>> >> >¬ Simon
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >Jeanne Waldman <jeanne.waldman@oracle.com >
>> >> >2006-08-18 18:27
>> >> >Please respond to adffaces-dev
>> >> >
>> >> > To: adffaces-dev@incubator.apache.org
>> >> > cc:
>> >> > Subject: Re: ADFFACES-49
>> inputText::content:required or
>> >> >inputText:required::content
>> >> >
>> >> >
>> >> >see inline for some random thoughts. :) I'm glad you brought
>> this up,
>> >> >because I need to come up with a solution soon for our internal
>> project
>> >> >that we are working on so that our developers can write their
>> renderers
>> >> >correctly.
>> >> >
>> >> >Simon_Lessard@DMR.CA wrote:
>> >> >
>> >> >
>> >> >
>> >> >>Hello all,
>> >> >>
>> >> >>I raised that issue a while back, but now it's a bit more important
>> >> since
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> >>I'm trying to finalize ADFFACES-49 issue. What selector synthax do
>> you
>> >> >>prefer for states:
>> >> >>1.1. <component>::<subPart>:<state>
>> >> >>1.2. <component>:<state>::<subPart>.
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >We use both syntaxes, and they mean different things.
>> >> >
>> >> >1.1 means this: The subPart of the component is in this state.
>> >> >For example:
>> >> >af|train::stop:disabled (when this train's stop is disabled, then
>> style
>> >> >the stop like this)
>> >> >af|train:disabled::stop (when the entire train is disabled, style
>> all
>> >> >the stops like this)
>> >> >
>> >> >1.2 means this: The component is in this state, and this is the
>> >> subpart.
>> >> >For example:
>> >> >af|inputText:disabled::content (when the af:inputText
>> disabled="true",
>> >> >then style the content piece like this)
>> >> >
>> >> >
>> >> >
>> >> >>I prefer the former and it's easier to implement. However, we
>> already
>> >> >>
>> >> >>
>> >> >have
>> >> >
>> >> >
>> >> >>some :disabled that use the latter synthax.
>> >> >>
>> >> >>Secondly, there's also the issue raised by Jeanne, how should we
>> >> manage
>> >> >>which states are intercepted and which should pass through and be
>> >> copied
>> >> >>in the final CSS:
>> >> >>2.1. Use a component specific list, so that :disabled could pass
>> >> through
>> >>
>> >> >>for some components but get intercepted for some others? If that
>> >> solution
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> >>is selected, how/where should we configure that list, in the
>> >> >>faces-config's metadata?
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >I like this one the best because let's say I use :disabled and I
>> >> >intercept it and do some funky things with it. Then let's say I
>> decide
>> >> >that the css spec deals
>> >> >with :disabled perfectly fine, and I don't need to intercept it.
>> >> >Also, let's say :hover and :active work great on some dom elements,
>> but
>> >> >do they work for everything?
>> >> >Let's say I have this: <span class="myText">Hello!</span> and this
>> css:
>> >> >.myText {color: black}
>> >> >.myText:hover {color:red}
>> >> >Does this work? (not in my tests)
>> >> >
>> >> >But what if this represents a component. I might want them to be
>> >> able to
>> >> >specify .myText:hover and have it work even if the built-in browser
>> >> >support wasn't there.
>> >> >So I would want
>> >> >af|myComponent:hover to work.
>> >> >I'd render this
>> >> ><span class="af_myComponent p_AFHover">Hello!</span>
>> >> >when they are hovering over my span.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >>2.2. Use a list of pseudo-classes passing through for all
>> components.
>> >> >>
>> >> >>
>> >> >Such
>> >> >
>> >> >
>> >> >>list would have to be based on W3C, but as Jeanne observed, such
>> list
>> >> >>would break our :disabled that we're intercepting currently and
>> could
>> >> >>
>> >> >>
>> >> >lead
>> >> >
>> >> >
>> >> >>to som.e problems if more pseudo-classes are added in future
>> >> version of
>> >> >>CSS.
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >Yes, I'd have to change the name of :disabled. But so far that is
>> the
>> >> >only css valid pseudo-class that I use to date.
>> >> >We have others like :hover (see above... if we don't want this to
>> pass
>> >> >through, we'll need to change it to something else).
>> >> >
>> >> >
>> >> >
>> >> >>2.3. Use a static list of pseudo-classes to intercept used by all
>> >> >>components? If so, where should we place it? This solution probably
>> >> has
>> >> >>the same flaws as 2.2 if a new pseudo-classes i nthe CSS
>> specification
>> >> >>matches a name defined in the intercept list.
>> >> >>2.4. Use a prefix for intercepted pseudo-classes like the -ora-
>> >> used for
>> >>
>> >> >>properties?
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >I like this second best. If we did this, then I'd suggest that we
>> also
>> >> >prefix the pseudo-elements.
>> >> >The problem is, taking my :hover example, some components might be
>> >> >rendered such that the browser
>> >> >automatically works with :hover on the generated css, but others
>> don't,
>> >> >so those that don't have to have
>> >> >:-tri-hover ?
>> >> >
>> >> >
>> >> >
>> >> >>My votes are:
>> >> >>+1 for 1.1
>> >> >>+1 for 2.2, but I would not place states resolvable during
>> >> rendering in
>> >> >>that list, so that disabled is still intercepted.
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >
>>
>>
>
Re: ADFFACES-49 inputText::content:required or inputText:required::content
Posted by Simon Lessard <si...@gmail.com>.
Hmmm, I'm leaning toward the per component basis option more and more.
However, I hate static lists and additional config files are not all that
great. I see a possibility though. Maybe it will work, but I did not explore
that area much yet so I might say something stupid. Currently it seem to me
that skins are linked to the renderkit. So, how feasible would it be to
create a SkinRenderKitFactory that would, before giving away any renderer,
would populate a Map<component, list<state>> be interrogating all renderers
in the kit. That way, when StyleSheetRenderer would do its work, we would be
sure that the list is populated. Also, with that solution, only the
renderers would have to know what states they want to intercept. This also
fix the synchronization issue, changing the kit or the renderer would
automatically update the interception list. We would have to create a new
BaseRenderer in the API however. I see two additional methods needed for
such renderers:
public String getComponentName() // or I guess getRootStyleClass would work
just as well
public List<String> getInterceptedStates(); // Returning the list of states
to intercept.
Makes sense?
~ Simon
On 8/21/06, Jeanne Waldman <je...@oracle.com> wrote:
>
> More comments inline.
> Which way are you leaning?
>
> - Jeanne
>
> Simon Lessard wrote:
>
> > Hello Jeanne,
> >
> > Thanks for the complete answer.
> >
> > On 8/21/06, Jeanne Waldman <jeanne.waldman@oracle.com > wrote:
> >
> >>
> >> Hi Simon,
> >> Thanks for the email.
> >>
> >> Simon_Lessard@DMR.CA wrote:
> >>
> >> >>We use both syntaxes, and they mean different things.
> >> >>For example:
> >> >>af|train::stop:disabled (when this train's stop is disabled, then
> >> style
> >> >>the stop like this)
> >> >>af|train:disabled::stop (when the entire train is disabled, style all
> >> >>the stops like this)
> >> >>
> >> >>
> >> >
> >> >Agreed.
> >> >
> >> >
> >> >
> >> >
> >> >>Let's say I have this: <span class="myText">Hello!</span> and this
> >> css:
> >> >>.myText {color: black}
> >> >>.myText:hover {color:red}
> >> >>Does this work? (not in my tests)
> >> >>
> >> >>
> >> >
> >> >It works in Firefox, not IE, as usual. W3C specifies that :hover
> should
> >> >work with everything, but it's not like all browsers will support
> >> >everything W3C says anytime soon. Maybe we should intercept all
> >> >pseudo-classes, if it can be resolved on Java side (like :disabled),
> we
> >> >resolve it there and it never pass through so we prevent all bad
> >> support
> >> >from the browser. For states that cannot be resolved in Java, we could
> >> ask
> >> >the Agent if it supports the specified pseudo-class for the generated
> >> >element (link:hover works in IE, but not on anything else). If the
> >> agent
> >> >supports it, we let the class pass through to the generated CSS
> >> file, if
> >> >the agent does not, then we could add some JS code to emulate it.
> >> >
> >> >
> >> We generate the css file before we render the components, so when you
> >> say we should intercept all pseudo-classes and if it can be resolved on
> >> the Java side, we should resolve it. But how would we know at this
> point
> >> where we are going to render the pseudo-class? that af|foo:hover will
> be
> >> generated on a link? Maybe af|foo:hover is on a <span>, but
> >> af|foo::step:hover is on the link. (we would know if we kept the
> >> skinning-key -> pseudo-class to resolve map). Or do you mean literally
> >> that if we can resolve it on the Java side -- even if the browser can
> as
> >> well -- we go ahead and do that?
> >
> >
> >
> > I mean litterally that we make a list of pseudo-classes that we know
> > we can
> > always resolve during rendering, like :disabled, and always intercept
> > it. In
> > a sense it would be a way to cover browsers' lack of support for those
> > pseudo-classes.
> >
> > In the case of :hover, do we pass that through for IE or not? Let's say
> >
> >> we don't pass it through for IE. Then we'll need some code that gets
> >> :hover and says, oh, we are on IE, so don't pass this through but
> >> instead do some onmouseover + css magic. This seems like it could get
> >> messy fast.
> >
> >
> >
> > Fair point, the renderers would have to check if there's a selector
> using
> > :hover defined in the current skin and add some JS, it's messy indeed.
> >
> >> The main problem I have the "per component" option is the potential
> >> >performance overhaul it represents as well as the increased component
> >> >development complexity (since you have to put more information in the
> >> >metadata).
> >> >
> >> >
> >> I don't think of this as a performance hit, since this will happen at
> >> the css generation time, not with every renderer. And we cache the
> >> generated css file.
> >> It would be like the map I have now in FileSystemStyleCache.
> >
> >
> >
> > Small question here. When is the CSS generated exactly? Is it at
> > startup or
> > at the first request for a given skin family? If it is during startup,
> > the
> > performance hit is indeed a non issue.
>
> rendered in StyleSheetRenderer. We get it out of the cache if it is
> there, otherwise we generate it.
>
> >
> > However, we would need to keep the renderer and this map in sync. For my
> >
> >> renderer 'foo', I know that I want to handle 'hover' myself, so I put
> >> the hover -> p_AFHover in the map that will be consulted when we
> >> generate the css file. af|foo:hover does not pass through. All other
> >> :hover passes through. I don't think this is that terrible. I like this
> >> better than the prefix, because if, down the line, we decide that we
> can
> >> pass through the pseudo-class, the user's skin will not have to change,
> >> but our code will get simpler.
> >
> >
> >
> > Not that bad, but I kind of dislike hard coded lists as component
> > developers
> > won't be able to use the skinning feature without giving it to Trinidad
> > project since they will have to hack Trinidad's jar file to add their
> own
> > states to the map. If that way is chosen, I would rather use another
> > configuration file or some faces-config meta-data entries. For now
> > skin is
> > not a public API, but I'm prety sure it will become one at some point in
> > time.
>
> We definitely need to get it out of FileSystemStyleCache. No doubt about
> it.
>
> >
> >> The prefix is ok, but I find it a bit counter intuitive since the
> >> user has
> >> >to know which states will be handled by browser and which are
> >> managed by
> >> >Trinidad. I would prefer to hide that kind of low level implementation
> >> >details to skinners.
> >> >
> >> >
> >> We would definitely document all the -tri- pseudo-classes per skinning
> >> key. For example:
> >> af|inputText:-tri-required, af|inputText:-tri-read-only,
> >> af|inputText:-tri-disabled. But for af|train::stop-link,
> >> we'd document that they can use :hover.
> >
> >
> >
> > It works, but it's a bit ugly imho. Furthermore, as you pointed out,
> such
> > solution would force skin CSS changes if we beside to let any given
> state
> > pass through in the future.
>
> true.
>
> >
> >> On a side note that could lead to a new post, what should we do with
> >> >icons? Currently the engine considers a selector an icon one if it
> ends
> >> >with -icon. This lead to some strange selectors sometimes like
> >> >-icon-style-class simply to prevent the parser to interpret it as an
> >> icon.
> >> >Maybe we should add something like :::icon, ::tri-icon or --icon? That
> >> way
> >> >there will be no ambiguity left.
> >> >
> >> >
> >> I don't have a problem with saying -icon-style when what you mean is
> >> that you want to style the icon, and ending the key with -icon when it
> >> means an icon.
> >
> >
> >
> > It's not that bad, true, but do we have a doc somewhere to document this
> > kind of skinning rules? If not, should I add a wiki entry for it even
> > if the
> > API is not public yet? Other things interesting I see are
> FileSystemCache
> > and the mandatory "af" namespace.
>
> We don't have a skinning document for Trinidad developers (as opposed to
> application developers using Trinidad).
> Starting a wiki would be great. I can populate it with some information
> I have.
>
> Yeah, the namespace is purely to make it so that the skinner knows there
> are Trinidad keys.
> We need to change these to tr for one thing. The code might be a little
> bit hardcoded to use 'af', so that will need to change.
> We don't honor the actual namespace in that you can't add @namespace to
> the top of the css file and then be able to use
> whatever prefix you want. That was very low priority when I was doing
> the skinning, and I'm not so sure we'd want to do that
> anyway, becuase what would we do, substitute the namespace for the
> prefix? Then our css would be huge. :) Maybe some day the
> browsers would work with the @namespace, and when that happens we can
> render it out to our css.
>
> >
> > - Jeanne
> >
> >>
> >> >
> >> >Regards
> >> >
> >> >¬ Simon
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >Jeanne Waldman <jeanne.waldman@oracle.com >
> >> >2006-08-18 18:27
> >> >Please respond to adffaces-dev
> >> >
> >> > To: adffaces-dev@incubator.apache.org
> >> > cc:
> >> > Subject: Re: ADFFACES-49 inputText::content:required or
> >> >inputText:required::content
> >> >
> >> >
> >> >see inline for some random thoughts. :) I'm glad you brought this up,
> >> >because I need to come up with a solution soon for our internal
> project
> >> >that we are working on so that our developers can write their
> renderers
> >> >correctly.
> >> >
> >> >Simon_Lessard@DMR.CA wrote:
> >> >
> >> >
> >> >
> >> >>Hello all,
> >> >>
> >> >>I raised that issue a while back, but now it's a bit more important
> >> since
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> >>I'm trying to finalize ADFFACES-49 issue. What selector synthax do
> you
> >> >>prefer for states:
> >> >>1.1. <component>::<subPart>:<state>
> >> >>1.2. <component>:<state>::<subPart>.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >We use both syntaxes, and they mean different things.
> >> >
> >> >1.1 means this: The subPart of the component is in this state.
> >> >For example:
> >> >af|train::stop:disabled (when this train's stop is disabled, then
> style
> >> >the stop like this)
> >> >af|train:disabled::stop (when the entire train is disabled, style all
> >> >the stops like this)
> >> >
> >> >1.2 means this: The component is in this state, and this is the
> >> subpart.
> >> >For example:
> >> >af|inputText:disabled::content (when the af:inputText disabled="true",
> >> >then style the content piece like this)
> >> >
> >> >
> >> >
> >> >>I prefer the former and it's easier to implement. However, we already
> >> >>
> >> >>
> >> >have
> >> >
> >> >
> >> >>some :disabled that use the latter synthax.
> >> >>
> >> >>Secondly, there's also the issue raised by Jeanne, how should we
> >> manage
> >> >>which states are intercepted and which should pass through and be
> >> copied
> >> >>in the final CSS:
> >> >>2.1. Use a component specific list, so that :disabled could pass
> >> through
> >>
> >> >>for some components but get intercepted for some others? If that
> >> solution
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> >>is selected, how/where should we configure that list, in the
> >> >>faces-config's metadata?
> >> >>
> >> >>
> >> >>
> >> >>
> >> >I like this one the best because let's say I use :disabled and I
> >> >intercept it and do some funky things with it. Then let's say I decide
> >> >that the css spec deals
> >> >with :disabled perfectly fine, and I don't need to intercept it.
> >> >Also, let's say :hover and :active work great on some dom elements,
> but
> >> >do they work for everything?
> >> >Let's say I have this: <span class="myText">Hello!</span> and this
> css:
> >> >.myText {color: black}
> >> >.myText:hover {color:red}
> >> >Does this work? (not in my tests)
> >> >
> >> >But what if this represents a component. I might want them to be
> >> able to
> >> >specify .myText:hover and have it work even if the built-in browser
> >> >support wasn't there.
> >> >So I would want
> >> >af|myComponent:hover to work.
> >> >I'd render this
> >> ><span class="af_myComponent p_AFHover">Hello!</span>
> >> >when they are hovering over my span.
> >> >
> >> >
> >> >
> >> >
> >> >>2.2. Use a list of pseudo-classes passing through for all components.
> >> >>
> >> >>
> >> >Such
> >> >
> >> >
> >> >>list would have to be based on W3C, but as Jeanne observed, such list
> >> >>would break our :disabled that we're intercepting currently and could
> >> >>
> >> >>
> >> >lead
> >> >
> >> >
> >> >>to som.e problems if more pseudo-classes are added in future
> >> version of
> >> >>CSS.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >Yes, I'd have to change the name of :disabled. But so far that is the
> >> >only css valid pseudo-class that I use to date.
> >> >We have others like :hover (see above... if we don't want this to pass
> >> >through, we'll need to change it to something else).
> >> >
> >> >
> >> >
> >> >>2.3. Use a static list of pseudo-classes to intercept used by all
> >> >>components? If so, where should we place it? This solution probably
> >> has
> >> >>the same flaws as 2.2 if a new pseudo-classes i nthe CSS
> specification
> >> >>matches a name defined in the intercept list.
> >> >>2.4. Use a prefix for intercepted pseudo-classes like the -ora-
> >> used for
> >>
> >> >>properties?
> >> >>
> >> >>
> >> >>
> >> >>
> >> >I like this second best. If we did this, then I'd suggest that we also
> >> >prefix the pseudo-elements.
> >> >The problem is, taking my :hover example, some components might be
> >> >rendered such that the browser
> >> >automatically works with :hover on the generated css, but others
> don't,
> >> >so those that don't have to have
> >> >:-tri-hover ?
> >> >
> >> >
> >> >
> >> >>My votes are:
> >> >>+1 for 1.1
> >> >>+1 for 2.2, but I would not place states resolvable during
> >> rendering in
> >> >>that list, so that disabled is still intercepted.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >
>
>
Re: ADFFACES-49 inputText::content:required or inputText:required::content
Posted by Jeanne Waldman <je...@oracle.com>.
More comments inline.
Which way are you leaning?
- Jeanne
Simon Lessard wrote:
> Hello Jeanne,
>
> Thanks for the complete answer.
>
> On 8/21/06, Jeanne Waldman <jeanne.waldman@oracle.com > wrote:
>
>>
>> Hi Simon,
>> Thanks for the email.
>>
>> Simon_Lessard@DMR.CA wrote:
>>
>> >>We use both syntaxes, and they mean different things.
>> >>For example:
>> >>af|train::stop:disabled (when this train's stop is disabled, then
>> style
>> >>the stop like this)
>> >>af|train:disabled::stop (when the entire train is disabled, style all
>> >>the stops like this)
>> >>
>> >>
>> >
>> >Agreed.
>> >
>> >
>> >
>> >
>> >>Let's say I have this: <span class="myText">Hello!</span> and this
>> css:
>> >>.myText {color: black}
>> >>.myText:hover {color:red}
>> >>Does this work? (not in my tests)
>> >>
>> >>
>> >
>> >It works in Firefox, not IE, as usual. W3C specifies that :hover should
>> >work with everything, but it's not like all browsers will support
>> >everything W3C says anytime soon. Maybe we should intercept all
>> >pseudo-classes, if it can be resolved on Java side (like :disabled), we
>> >resolve it there and it never pass through so we prevent all bad
>> support
>> >from the browser. For states that cannot be resolved in Java, we could
>> ask
>> >the Agent if it supports the specified pseudo-class for the generated
>> >element (link:hover works in IE, but not on anything else). If the
>> agent
>> >supports it, we let the class pass through to the generated CSS
>> file, if
>> >the agent does not, then we could add some JS code to emulate it.
>> >
>> >
>> We generate the css file before we render the components, so when you
>> say we should intercept all pseudo-classes and if it can be resolved on
>> the Java side, we should resolve it. But how would we know at this point
>> where we are going to render the pseudo-class? that af|foo:hover will be
>> generated on a link? Maybe af|foo:hover is on a <span>, but
>> af|foo::step:hover is on the link. (we would know if we kept the
>> skinning-key -> pseudo-class to resolve map). Or do you mean literally
>> that if we can resolve it on the Java side -- even if the browser can as
>> well -- we go ahead and do that?
>
>
>
> I mean litterally that we make a list of pseudo-classes that we know
> we can
> always resolve during rendering, like :disabled, and always intercept
> it. In
> a sense it would be a way to cover browsers' lack of support for those
> pseudo-classes.
>
> In the case of :hover, do we pass that through for IE or not? Let's say
>
>> we don't pass it through for IE. Then we'll need some code that gets
>> :hover and says, oh, we are on IE, so don't pass this through but
>> instead do some onmouseover + css magic. This seems like it could get
>> messy fast.
>
>
>
> Fair point, the renderers would have to check if there's a selector using
> :hover defined in the current skin and add some JS, it's messy indeed.
>
>> The main problem I have the "per component" option is the potential
>> >performance overhaul it represents as well as the increased component
>> >development complexity (since you have to put more information in the
>> >metadata).
>> >
>> >
>> I don't think of this as a performance hit, since this will happen at
>> the css generation time, not with every renderer. And we cache the
>> generated css file.
>> It would be like the map I have now in FileSystemStyleCache.
>
>
>
> Small question here. When is the CSS generated exactly? Is it at
> startup or
> at the first request for a given skin family? If it is during startup,
> the
> performance hit is indeed a non issue.
rendered in StyleSheetRenderer. We get it out of the cache if it is
there, otherwise we generate it.
>
> However, we would need to keep the renderer and this map in sync. For my
>
>> renderer 'foo', I know that I want to handle 'hover' myself, so I put
>> the hover -> p_AFHover in the map that will be consulted when we
>> generate the css file. af|foo:hover does not pass through. All other
>> :hover passes through. I don't think this is that terrible. I like this
>> better than the prefix, because if, down the line, we decide that we can
>> pass through the pseudo-class, the user's skin will not have to change,
>> but our code will get simpler.
>
>
>
> Not that bad, but I kind of dislike hard coded lists as component
> developers
> won't be able to use the skinning feature without giving it to Trinidad
> project since they will have to hack Trinidad's jar file to add their own
> states to the map. If that way is chosen, I would rather use another
> configuration file or some faces-config meta-data entries. For now
> skin is
> not a public API, but I'm prety sure it will become one at some point in
> time.
We definitely need to get it out of FileSystemStyleCache. No doubt about it.
>
>> The prefix is ok, but I find it a bit counter intuitive since the
>> user has
>> >to know which states will be handled by browser and which are
>> managed by
>> >Trinidad. I would prefer to hide that kind of low level implementation
>> >details to skinners.
>> >
>> >
>> We would definitely document all the -tri- pseudo-classes per skinning
>> key. For example:
>> af|inputText:-tri-required, af|inputText:-tri-read-only,
>> af|inputText:-tri-disabled. But for af|train::stop-link,
>> we'd document that they can use :hover.
>
>
>
> It works, but it's a bit ugly imho. Furthermore, as you pointed out, such
> solution would force skin CSS changes if we beside to let any given state
> pass through in the future.
true.
>
>> On a side note that could lead to a new post, what should we do with
>> >icons? Currently the engine considers a selector an icon one if it ends
>> >with -icon. This lead to some strange selectors sometimes like
>> >-icon-style-class simply to prevent the parser to interpret it as an
>> icon.
>> >Maybe we should add something like :::icon, ::tri-icon or --icon? That
>> way
>> >there will be no ambiguity left.
>> >
>> >
>> I don't have a problem with saying -icon-style when what you mean is
>> that you want to style the icon, and ending the key with -icon when it
>> means an icon.
>
>
>
> It's not that bad, true, but do we have a doc somewhere to document this
> kind of skinning rules? If not, should I add a wiki entry for it even
> if the
> API is not public yet? Other things interesting I see are FileSystemCache
> and the mandatory "af" namespace.
We don't have a skinning document for Trinidad developers (as opposed to
application developers using Trinidad).
Starting a wiki would be great. I can populate it with some information
I have.
Yeah, the namespace is purely to make it so that the skinner knows there
are Trinidad keys.
We need to change these to tr for one thing. The code might be a little
bit hardcoded to use 'af', so that will need to change.
We don't honor the actual namespace in that you can't add @namespace to
the top of the css file and then be able to use
whatever prefix you want. That was very low priority when I was doing
the skinning, and I'm not so sure we'd want to do that
anyway, becuase what would we do, substitute the namespace for the
prefix? Then our css would be huge. :) Maybe some day the
browsers would work with the @namespace, and when that happens we can
render it out to our css.
>
> - Jeanne
>
>>
>> >
>> >Regards
>> >
>> >¬ Simon
>> >
>> >
>> >
>> >
>> >
>> >
>> >Jeanne Waldman <jeanne.waldman@oracle.com >
>> >2006-08-18 18:27
>> >Please respond to adffaces-dev
>> >
>> > To: adffaces-dev@incubator.apache.org
>> > cc:
>> > Subject: Re: ADFFACES-49 inputText::content:required or
>> >inputText:required::content
>> >
>> >
>> >see inline for some random thoughts. :) I'm glad you brought this up,
>> >because I need to come up with a solution soon for our internal project
>> >that we are working on so that our developers can write their renderers
>> >correctly.
>> >
>> >Simon_Lessard@DMR.CA wrote:
>> >
>> >
>> >
>> >>Hello all,
>> >>
>> >>I raised that issue a while back, but now it's a bit more important
>> since
>> >>
>> >>
>> >
>> >
>> >
>> >>I'm trying to finalize ADFFACES-49 issue. What selector synthax do you
>> >>prefer for states:
>> >>1.1. <component>::<subPart>:<state>
>> >>1.2. <component>:<state>::<subPart>.
>> >>
>> >>
>> >>
>> >>
>> >We use both syntaxes, and they mean different things.
>> >
>> >1.1 means this: The subPart of the component is in this state.
>> >For example:
>> >af|train::stop:disabled (when this train's stop is disabled, then style
>> >the stop like this)
>> >af|train:disabled::stop (when the entire train is disabled, style all
>> >the stops like this)
>> >
>> >1.2 means this: The component is in this state, and this is the
>> subpart.
>> >For example:
>> >af|inputText:disabled::content (when the af:inputText disabled="true",
>> >then style the content piece like this)
>> >
>> >
>> >
>> >>I prefer the former and it's easier to implement. However, we already
>> >>
>> >>
>> >have
>> >
>> >
>> >>some :disabled that use the latter synthax.
>> >>
>> >>Secondly, there's also the issue raised by Jeanne, how should we
>> manage
>> >>which states are intercepted and which should pass through and be
>> copied
>> >>in the final CSS:
>> >>2.1. Use a component specific list, so that :disabled could pass
>> through
>>
>> >>for some components but get intercepted for some others? If that
>> solution
>> >>
>> >>
>> >
>> >
>> >
>> >>is selected, how/where should we configure that list, in the
>> >>faces-config's metadata?
>> >>
>> >>
>> >>
>> >>
>> >I like this one the best because let's say I use :disabled and I
>> >intercept it and do some funky things with it. Then let's say I decide
>> >that the css spec deals
>> >with :disabled perfectly fine, and I don't need to intercept it.
>> >Also, let's say :hover and :active work great on some dom elements, but
>> >do they work for everything?
>> >Let's say I have this: <span class="myText">Hello!</span> and this css:
>> >.myText {color: black}
>> >.myText:hover {color:red}
>> >Does this work? (not in my tests)
>> >
>> >But what if this represents a component. I might want them to be
>> able to
>> >specify .myText:hover and have it work even if the built-in browser
>> >support wasn't there.
>> >So I would want
>> >af|myComponent:hover to work.
>> >I'd render this
>> ><span class="af_myComponent p_AFHover">Hello!</span>
>> >when they are hovering over my span.
>> >
>> >
>> >
>> >
>> >>2.2. Use a list of pseudo-classes passing through for all components.
>> >>
>> >>
>> >Such
>> >
>> >
>> >>list would have to be based on W3C, but as Jeanne observed, such list
>> >>would break our :disabled that we're intercepting currently and could
>> >>
>> >>
>> >lead
>> >
>> >
>> >>to som.e problems if more pseudo-classes are added in future
>> version of
>> >>CSS.
>> >>
>> >>
>> >>
>> >>
>> >Yes, I'd have to change the name of :disabled. But so far that is the
>> >only css valid pseudo-class that I use to date.
>> >We have others like :hover (see above... if we don't want this to pass
>> >through, we'll need to change it to something else).
>> >
>> >
>> >
>> >>2.3. Use a static list of pseudo-classes to intercept used by all
>> >>components? If so, where should we place it? This solution probably
>> has
>> >>the same flaws as 2.2 if a new pseudo-classes i nthe CSS specification
>> >>matches a name defined in the intercept list.
>> >>2.4. Use a prefix for intercepted pseudo-classes like the -ora-
>> used for
>>
>> >>properties?
>> >>
>> >>
>> >>
>> >>
>> >I like this second best. If we did this, then I'd suggest that we also
>> >prefix the pseudo-elements.
>> >The problem is, taking my :hover example, some components might be
>> >rendered such that the browser
>> >automatically works with :hover on the generated css, but others don't,
>> >so those that don't have to have
>> >:-tri-hover ?
>> >
>> >
>> >
>> >>My votes are:
>> >>+1 for 1.1
>> >>+1 for 2.2, but I would not place states resolvable during
>> rendering in
>> >>that list, so that disabled is still intercepted.
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> >
>> >
>> >
>>
>>
>
Re: ADFFACES-49 inputText::content:required or inputText:required::content
Posted by Simon Lessard <si...@gmail.com>.
Hello Jeanne,
Thanks for the complete answer.
On 8/21/06, Jeanne Waldman <jeanne.waldman@oracle.com > wrote:
>
> Hi Simon,
> Thanks for the email.
>
> Simon_Lessard@DMR.CA wrote:
>
> >>We use both syntaxes, and they mean different things.
> >>For example:
> >>af|train::stop:disabled (when this train's stop is disabled, then style
> >>the stop like this)
> >>af|train:disabled::stop (when the entire train is disabled, style all
> >>the stops like this)
> >>
> >>
> >
> >Agreed.
> >
> >
> >
> >
> >>Let's say I have this: <span class="myText">Hello!</span> and this css:
> >>.myText {color: black}
> >>.myText:hover {color:red}
> >>Does this work? (not in my tests)
> >>
> >>
> >
> >It works in Firefox, not IE, as usual. W3C specifies that :hover should
> >work with everything, but it's not like all browsers will support
> >everything W3C says anytime soon. Maybe we should intercept all
> >pseudo-classes, if it can be resolved on Java side (like :disabled), we
> >resolve it there and it never pass through so we prevent all bad support
> >from the browser. For states that cannot be resolved in Java, we could
> ask
> >the Agent if it supports the specified pseudo-class for the generated
> >element (link:hover works in IE, but not on anything else). If the agent
> >supports it, we let the class pass through to the generated CSS file, if
> >the agent does not, then we could add some JS code to emulate it.
> >
> >
> We generate the css file before we render the components, so when you
> say we should intercept all pseudo-classes and if it can be resolved on
> the Java side, we should resolve it. But how would we know at this point
> where we are going to render the pseudo-class? that af|foo:hover will be
> generated on a link? Maybe af|foo:hover is on a <span>, but
> af|foo::step:hover is on the link. (we would know if we kept the
> skinning-key -> pseudo-class to resolve map). Or do you mean literally
> that if we can resolve it on the Java side -- even if the browser can as
> well -- we go ahead and do that?
I mean litterally that we make a list of pseudo-classes that we know we can
always resolve during rendering, like :disabled, and always intercept it. In
a sense it would be a way to cover browsers' lack of support for those
pseudo-classes.
In the case of :hover, do we pass that through for IE or not? Let's say
> we don't pass it through for IE. Then we'll need some code that gets
> :hover and says, oh, we are on IE, so don't pass this through but
> instead do some onmouseover + css magic. This seems like it could get
> messy fast.
Fair point, the renderers would have to check if there's a selector using
:hover defined in the current skin and add some JS, it's messy indeed.
>The main problem I have the "per component" option is the potential
> >performance overhaul it represents as well as the increased component
> >development complexity (since you have to put more information in the
> >metadata).
> >
> >
> I don't think of this as a performance hit, since this will happen at
> the css generation time, not with every renderer. And we cache the
> generated css file.
> It would be like the map I have now in FileSystemStyleCache.
Small question here. When is the CSS generated exactly? Is it at startup or
at the first request for a given skin family? If it is during startup, the
performance hit is indeed a non issue.
However, we would need to keep the renderer and this map in sync. For my
> renderer 'foo', I know that I want to handle 'hover' myself, so I put
> the hover -> p_AFHover in the map that will be consulted when we
> generate the css file. af|foo:hover does not pass through. All other
> :hover passes through. I don't think this is that terrible. I like this
> better than the prefix, because if, down the line, we decide that we can
> pass through the pseudo-class, the user's skin will not have to change,
> but our code will get simpler.
Not that bad, but I kind of dislike hard coded lists as component developers
won't be able to use the skinning feature without giving it to Trinidad
project since they will have to hack Trinidad's jar file to add their own
states to the map. If that way is chosen, I would rather use another
configuration file or some faces-config meta-data entries. For now skin is
not a public API, but I'm prety sure it will become one at some point in
time.
>The prefix is ok, but I find it a bit counter intuitive since the user has
> >to know which states will be handled by browser and which are managed by
> >Trinidad. I would prefer to hide that kind of low level implementation
> >details to skinners.
> >
> >
> We would definitely document all the -tri- pseudo-classes per skinning
> key. For example:
> af|inputText:-tri-required, af|inputText:-tri-read-only,
> af|inputText:-tri-disabled. But for af|train::stop-link,
> we'd document that they can use :hover.
It works, but it's a bit ugly imho. Furthermore, as you pointed out, such
solution would force skin CSS changes if we beside to let any given state
pass through in the future.
>On a side note that could lead to a new post, what should we do with
> >icons? Currently the engine considers a selector an icon one if it ends
> >with -icon. This lead to some strange selectors sometimes like
> >-icon-style-class simply to prevent the parser to interpret it as an
> icon.
> >Maybe we should add something like :::icon, ::tri-icon or --icon? That
> way
> >there will be no ambiguity left.
> >
> >
> I don't have a problem with saying -icon-style when what you mean is
> that you want to style the icon, and ending the key with -icon when it
> means an icon.
It's not that bad, true, but do we have a doc somewhere to document this
kind of skinning rules? If not, should I add a wiki entry for it even if the
API is not public yet? Other things interesting I see are FileSystemCache
and the mandatory "af" namespace.
- Jeanne
>
> >
> >Regards
> >
> >¬ Simon
> >
> >
> >
> >
> >
> >
> >Jeanne Waldman <jeanne.waldman@oracle.com >
> >2006-08-18 18:27
> >Please respond to adffaces-dev
> >
> > To: adffaces-dev@incubator.apache.org
> > cc:
> > Subject: Re: ADFFACES-49 inputText::content:required or
> >inputText:required::content
> >
> >
> >see inline for some random thoughts. :) I'm glad you brought this up,
> >because I need to come up with a solution soon for our internal project
> >that we are working on so that our developers can write their renderers
> >correctly.
> >
> >Simon_Lessard@DMR.CA wrote:
> >
> >
> >
> >>Hello all,
> >>
> >>I raised that issue a while back, but now it's a bit more important
> since
> >>
> >>
> >
> >
> >
> >>I'm trying to finalize ADFFACES-49 issue. What selector synthax do you
> >>prefer for states:
> >>1.1. <component>::<subPart>:<state>
> >>1.2. <component>:<state>::<subPart>.
> >>
> >>
> >>
> >>
> >We use both syntaxes, and they mean different things.
> >
> >1.1 means this: The subPart of the component is in this state.
> >For example:
> >af|train::stop:disabled (when this train's stop is disabled, then style
> >the stop like this)
> >af|train:disabled::stop (when the entire train is disabled, style all
> >the stops like this)
> >
> >1.2 means this: The component is in this state, and this is the subpart.
> >For example:
> >af|inputText:disabled::content (when the af:inputText disabled="true",
> >then style the content piece like this)
> >
> >
> >
> >>I prefer the former and it's easier to implement. However, we already
> >>
> >>
> >have
> >
> >
> >>some :disabled that use the latter synthax.
> >>
> >>Secondly, there's also the issue raised by Jeanne, how should we manage
> >>which states are intercepted and which should pass through and be copied
> >>in the final CSS:
> >>2.1. Use a component specific list, so that :disabled could pass through
>
> >>for some components but get intercepted for some others? If that
> solution
> >>
> >>
> >
> >
> >
> >>is selected, how/where should we configure that list, in the
> >>faces-config's metadata?
> >>
> >>
> >>
> >>
> >I like this one the best because let's say I use :disabled and I
> >intercept it and do some funky things with it. Then let's say I decide
> >that the css spec deals
> >with :disabled perfectly fine, and I don't need to intercept it.
> >Also, let's say :hover and :active work great on some dom elements, but
> >do they work for everything?
> >Let's say I have this: <span class="myText">Hello!</span> and this css:
> >.myText {color: black}
> >.myText:hover {color:red}
> >Does this work? (not in my tests)
> >
> >But what if this represents a component. I might want them to be able to
> >specify .myText:hover and have it work even if the built-in browser
> >support wasn't there.
> >So I would want
> >af|myComponent:hover to work.
> >I'd render this
> ><span class="af_myComponent p_AFHover">Hello!</span>
> >when they are hovering over my span.
> >
> >
> >
> >
> >>2.2. Use a list of pseudo-classes passing through for all components.
> >>
> >>
> >Such
> >
> >
> >>list would have to be based on W3C, but as Jeanne observed, such list
> >>would break our :disabled that we're intercepting currently and could
> >>
> >>
> >lead
> >
> >
> >>to som.e problems if more pseudo-classes are added in future version of
> >>CSS.
> >>
> >>
> >>
> >>
> >Yes, I'd have to change the name of :disabled. But so far that is the
> >only css valid pseudo-class that I use to date.
> >We have others like :hover (see above... if we don't want this to pass
> >through, we'll need to change it to something else).
> >
> >
> >
> >>2.3. Use a static list of pseudo-classes to intercept used by all
> >>components? If so, where should we place it? This solution probably has
> >>the same flaws as 2.2 if a new pseudo-classes i nthe CSS specification
> >>matches a name defined in the intercept list.
> >>2.4. Use a prefix for intercepted pseudo-classes like the -ora- used for
>
> >>properties?
> >>
> >>
> >>
> >>
> >I like this second best. If we did this, then I'd suggest that we also
> >prefix the pseudo-elements.
> >The problem is, taking my :hover example, some components might be
> >rendered such that the browser
> >automatically works with :hover on the generated css, but others don't,
> >so those that don't have to have
> >:-tri-hover ?
> >
> >
> >
> >>My votes are:
> >>+1 for 1.1
> >>+1 for 2.2, but I would not place states resolvable during rendering in
> >>that list, so that disabled is still intercepted.
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
>
>
Re: ADFFACES-49 inputText::content:required or inputText:required::content
Posted by Jeanne Waldman <je...@oracle.com>.
Hi Simon,
Thanks for the email.
Simon_Lessard@DMR.CA wrote:
>>We use both syntaxes, and they mean different things.
>>For example:
>>af|train::stop:disabled (when this train's stop is disabled, then style
>>the stop like this)
>>af|train:disabled::stop (when the entire train is disabled, style all
>>the stops like this)
>>
>>
>
>Agreed.
>
>
>
>
>>Let's say I have this: <span class="myText">Hello!</span> and this css:
>>.myText {color: black}
>>.myText:hover {color:red}
>>Does this work? (not in my tests)
>>
>>
>
>It works in Firefox, not IE, as usual. W3C specifies that :hover should
>work with everything, but it's not like all browsers will support
>everything W3C says anytime soon. Maybe we should intercept all
>pseudo-classes, if it can be resolved on Java side (like :disabled), we
>resolve it there and it never pass through so we prevent all bad support
>from the browser. For states that cannot be resolved in Java, we could ask
>the Agent if it supports the specified pseudo-class for the generated
>element (link:hover works in IE, but not on anything else). If the agent
>supports it, we let the class pass through to the generated CSS file, if
>the agent does not, then we could add some JS code to emulate it.
>
>
We generate the css file before we render the components, so when you
say we should intercept all pseudo-classes and if it can be resolved on
the Java side, we should resolve it. But how would we know at this point
where we are going to render the pseudo-class? that af|foo:hover will be
generated on a link? Maybe af|foo:hover is on a <span>, but
af|foo::step:hover is on the link. (we would know if we kept the
skinning-key -> pseudo-class to resolve map). Or do you mean literally
that if we can resolve it on the Java side -- even if the browser can as
well -- we go ahead and do that?
In the case of :hover, do we pass that through for IE or not? Let's say
we don't pass it through for IE. Then we'll need some code that gets
:hover and says, oh, we are on IE, so don't pass this through but
instead do some onmouseover + css magic. This seems like it could get
messy fast.
>The main problem I have the "per component" option is the potential
>performance overhaul it represents as well as the increased component
>development complexity (since you have to put more information in the
>metadata).
>
>
I don't think of this as a performance hit, since this will happen at
the css generation time, not with every renderer. And we cache the
generated css file.
It would be like the map I have now in FileSystemStyleCache.
However, we would need to keep the renderer and this map in sync. For my
renderer 'foo', I know that I want to handle 'hover' myself, so I put
the hover -> p_AFHover in the map that will be consulted when we
generate the css file. af|foo:hover does not pass through. All other
:hover passes through. I don't think this is that terrible. I like this
better than the prefix, because if, down the line, we decide that we can
pass through the pseudo-class, the user's skin will not have to change,
but our code will get simpler.
>The prefix is ok, but I find it a bit counter intuitive since the user has
>to know which states will be handled by browser and which are managed by
>Trinidad. I would prefer to hide that kind of low level implementation
>details to skinners.
>
>
We would definitely document all the -tri- pseudo-classes per skinning
key. For example:
af|inputText:-tri-required, af|inputText:-tri-read-only,
af|inputText:-tri-disabled. But for af|train::stop-link,
we'd document that they can use :hover.
>On a side note that could lead to a new post, what should we do with
>icons? Currently the engine considers a selector an icon one if it ends
>with -icon. This lead to some strange selectors sometimes like
>-icon-style-class simply to prevent the parser to interpret it as an icon.
>Maybe we should add something like :::icon, ::tri-icon or --icon? That way
>there will be no ambiguity left.
>
>
I don't have a problem with saying -icon-style when what you mean is
that you want to style the icon, and ending the key with -icon when it
means an icon.
- Jeanne
>
>Regards
>
>¬ Simon
>
>
>
>
>
>
>Jeanne Waldman <je...@oracle.com>
>2006-08-18 18:27
>Please respond to adffaces-dev
>
> To: adffaces-dev@incubator.apache.org
> cc:
> Subject: Re: ADFFACES-49 inputText::content:required or
>inputText:required::content
>
>
>see inline for some random thoughts. :) I'm glad you brought this up,
>because I need to come up with a solution soon for our internal project
>that we are working on so that our developers can write their renderers
>correctly.
>
>Simon_Lessard@DMR.CA wrote:
>
>
>
>>Hello all,
>>
>>I raised that issue a while back, but now it's a bit more important since
>>
>>
>
>
>
>>I'm trying to finalize ADFFACES-49 issue. What selector synthax do you
>>prefer for states:
>>1.1. <component>::<subPart>:<state>
>>1.2. <component>:<state>::<subPart>.
>>
>>
>>
>>
>We use both syntaxes, and they mean different things.
>
>1.1 means this: The subPart of the component is in this state.
>For example:
>af|train::stop:disabled (when this train's stop is disabled, then style
>the stop like this)
>af|train:disabled::stop (when the entire train is disabled, style all
>the stops like this)
>
>1.2 means this: The component is in this state, and this is the subpart.
>For example:
>af|inputText:disabled::content (when the af:inputText disabled="true",
>then style the content piece like this)
>
>
>
>>I prefer the former and it's easier to implement. However, we already
>>
>>
>have
>
>
>>some :disabled that use the latter synthax.
>>
>>Secondly, there's also the issue raised by Jeanne, how should we manage
>>which states are intercepted and which should pass through and be copied
>>in the final CSS:
>>2.1. Use a component specific list, so that :disabled could pass through
>>for some components but get intercepted for some others? If that solution
>>
>>
>
>
>
>>is selected, how/where should we configure that list, in the
>>faces-config's metadata?
>>
>>
>>
>>
>I like this one the best because let's say I use :disabled and I
>intercept it and do some funky things with it. Then let's say I decide
>that the css spec deals
>with :disabled perfectly fine, and I don't need to intercept it.
>Also, let's say :hover and :active work great on some dom elements, but
>do they work for everything?
>Let's say I have this: <span class="myText">Hello!</span> and this css:
>.myText {color: black}
>.myText:hover {color:red}
>Does this work? (not in my tests)
>
>But what if this represents a component. I might want them to be able to
>specify .myText:hover and have it work even if the built-in browser
>support wasn't there.
>So I would want
>af|myComponent:hover to work.
>I'd render this
><span class="af_myComponent p_AFHover">Hello!</span>
>when they are hovering over my span.
>
>
>
>
>>2.2. Use a list of pseudo-classes passing through for all components.
>>
>>
>Such
>
>
>>list would have to be based on W3C, but as Jeanne observed, such list
>>would break our :disabled that we're intercepting currently and could
>>
>>
>lead
>
>
>>to som.e problems if more pseudo-classes are added in future version of
>>CSS.
>>
>>
>>
>>
>Yes, I'd have to change the name of :disabled. But so far that is the
>only css valid pseudo-class that I use to date.
>We have others like :hover (see above... if we don't want this to pass
>through, we'll need to change it to something else).
>
>
>
>>2.3. Use a static list of pseudo-classes to intercept used by all
>>components? If so, where should we place it? This solution probably has
>>the same flaws as 2.2 if a new pseudo-classes i nthe CSS specification
>>matches a name defined in the intercept list.
>>2.4. Use a prefix for intercepted pseudo-classes like the -ora- used for
>>properties?
>>
>>
>>
>>
>I like this second best. If we did this, then I'd suggest that we also
>prefix the pseudo-elements.
>The problem is, taking my :hover example, some components might be
>rendered such that the browser
>automatically works with :hover on the generated css, but others don't,
>so those that don't have to have
>:-tri-hover ?
>
>
>
>>My votes are:
>>+1 for 1.1
>>+1 for 2.2, but I would not place states resolvable during rendering in
>>that list, so that disabled is still intercepted.
>>
>>
>>
>>
>
>
>
>
>
Re: unsubscribe
Posted by Si...@DMR.CA.
Hello LAW CHOR HIONG,
Please use adffaces-dev-unsubscribe@incubator.apache.org to unsubscribe
from this list.
Regards,
¬ Simon
unsubscribe
Posted by LAW CHOR HIONG <CH...@y3technologies.com>.
-----Original Message-----
From: Simon_Lessard@DMR.CA [mailto:Simon_Lessard@DMR.CA]
Sent: Monday, August 21, 2006 2:43 AM
To: adffaces-dev@incubator.apache.org
Subject: Re: ADFFACES-49 inputText::content:required or inputText:required::content
> We use both syntaxes, and they mean different things.
> For example:
> af|train::stop:disabled (when this train's stop is disabled, then style
> the stop like this)
> af|train:disabled::stop (when the entire train is disabled, style all
> the stops like this)
Agreed.
> Let's say I have this: <span class="myText">Hello!</span> and this css:
> .myText {color: black}
> .myText:hover {color:red}
> Does this work? (not in my tests)
It works in Firefox, not IE, as usual. W3C specifies that :hover should
work with everything, but it's not like all browsers will support
everything W3C says anytime soon. Maybe we should intercept all
pseudo-classes, if it can be resolved on Java side (like :disabled), we
resolve it there and it never pass through so we prevent all bad support
from the browser. For states that cannot be resolved in Java, we could ask
the Agent if it supports the specified pseudo-class for the generated
element (link:hover works in IE, but not on anything else). If the agent
supports it, we let the class pass through to the generated CSS file, if
the agent does not, then we could add some JS code to emulate it.
The main problem I have the "per component" option is the potential
performance overhaul it represents as well as the increased component
development complexity (since you have to put more information in the
metadata).
The prefix is ok, but I find it a bit counter intuitive since the user has
to know which states will be handled by browser and which are managed by
Trinidad. I would prefer to hide that kind of low level implementation
details to skinners.
On a side note that could lead to a new post, what should we do with
icons? Currently the engine considers a selector an icon one if it ends
with -icon. This lead to some strange selectors sometimes like
-icon-style-class simply to prevent the parser to interpret it as an icon.
Maybe we should add something like :::icon, ::tri-icon or --icon? That way
there will be no ambiguity left.
Regards
¬ Simon
Jeanne Waldman <je...@oracle.com>
2006-08-18 18:27
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject: Re: ADFFACES-49 inputText::content:required or
inputText:required::content
see inline for some random thoughts. :) I'm glad you brought this up,
because I need to come up with a solution soon for our internal project
that we are working on so that our developers can write their renderers
correctly.
Simon_Lessard@DMR.CA wrote:
>Hello all,
>
>I raised that issue a while back, but now it's a bit more important since
>I'm trying to finalize ADFFACES-49 issue. What selector synthax do you
>prefer for states:
>1.1. <component>::<subPart>:<state>
>1.2. <component>:<state>::<subPart>.
>
>
We use both syntaxes, and they mean different things.
1.1 means this: The subPart of the component is in this state.
For example:
af|train::stop:disabled (when this train's stop is disabled, then style
the stop like this)
af|train:disabled::stop (when the entire train is disabled, style all
the stops like this)
1.2 means this: The component is in this state, and this is the subpart.
For example:
af|inputText:disabled::content (when the af:inputText disabled="true",
then style the content piece like this)
>I prefer the former and it's easier to implement. However, we already
have
>some :disabled that use the latter synthax.
>
>Secondly, there's also the issue raised by Jeanne, how should we manage
>which states are intercepted and which should pass through and be copied
>in the final CSS:
>2.1. Use a component specific list, so that :disabled could pass through
>for some components but get intercepted for some others? If that solution
>is selected, how/where should we configure that list, in the
>faces-config's metadata?
>
>
I like this one the best because let's say I use :disabled and I
intercept it and do some funky things with it. Then let's say I decide
that the css spec deals
with :disabled perfectly fine, and I don't need to intercept it.
Also, let's say :hover and :active work great on some dom elements, but
do they work for everything?
Let's say I have this: <span class="myText">Hello!</span> and this css:
.myText {color: black}
.myText:hover {color:red}
Does this work? (not in my tests)
But what if this represents a component. I might want them to be able to
specify .myText:hover and have it work even if the built-in browser
support wasn't there.
So I would want
af|myComponent:hover to work.
I'd render this
<span class="af_myComponent p_AFHover">Hello!</span>
when they are hovering over my span.
>2.2. Use a list of pseudo-classes passing through for all components.
Such
>list would have to be based on W3C, but as Jeanne observed, such list
>would break our :disabled that we're intercepting currently and could
lead
>to som.e problems if more pseudo-classes are added in future version of
>CSS.
>
>
Yes, I'd have to change the name of :disabled. But so far that is the
only css valid pseudo-class that I use to date.
We have others like :hover (see above... if we don't want this to pass
through, we'll need to change it to something else).
>2.3. Use a static list of pseudo-classes to intercept used by all
>components? If so, where should we place it? This solution probably has
>the same flaws as 2.2 if a new pseudo-classes i nthe CSS specification
>matches a name defined in the intercept list.
>2.4. Use a prefix for intercepted pseudo-classes like the -ora- used for
>properties?
>
>
I like this second best. If we did this, then I'd suggest that we also
prefix the pseudo-elements.
The problem is, taking my :hover example, some components might be
rendered such that the browser
automatically works with :hover on the generated css, but others don't,
so those that don't have to have
:-tri-hover ?
>
>My votes are:
>+1 for 1.1
>+1 for 2.2, but I would not place states resolvable during rendering in
>that list, so that disabled is still intercepted.
>
>
Re: ADFFACES-49 inputText::content:required or inputText:required::content
Posted by Si...@DMR.CA.
> We use both syntaxes, and they mean different things.
> For example:
> af|train::stop:disabled (when this train's stop is disabled, then style
> the stop like this)
> af|train:disabled::stop (when the entire train is disabled, style all
> the stops like this)
Agreed.
> Let's say I have this: <span class="myText">Hello!</span> and this css:
> .myText {color: black}
> .myText:hover {color:red}
> Does this work? (not in my tests)
It works in Firefox, not IE, as usual. W3C specifies that :hover should
work with everything, but it's not like all browsers will support
everything W3C says anytime soon. Maybe we should intercept all
pseudo-classes, if it can be resolved on Java side (like :disabled), we
resolve it there and it never pass through so we prevent all bad support
from the browser. For states that cannot be resolved in Java, we could ask
the Agent if it supports the specified pseudo-class for the generated
element (link:hover works in IE, but not on anything else). If the agent
supports it, we let the class pass through to the generated CSS file, if
the agent does not, then we could add some JS code to emulate it.
The main problem I have the "per component" option is the potential
performance overhaul it represents as well as the increased component
development complexity (since you have to put more information in the
metadata).
The prefix is ok, but I find it a bit counter intuitive since the user has
to know which states will be handled by browser and which are managed by
Trinidad. I would prefer to hide that kind of low level implementation
details to skinners.
On a side note that could lead to a new post, what should we do with
icons? Currently the engine considers a selector an icon one if it ends
with -icon. This lead to some strange selectors sometimes like
-icon-style-class simply to prevent the parser to interpret it as an icon.
Maybe we should add something like :::icon, ::tri-icon or --icon? That way
there will be no ambiguity left.
Regards
¬ Simon
Jeanne Waldman <je...@oracle.com>
2006-08-18 18:27
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject: Re: ADFFACES-49 inputText::content:required or
inputText:required::content
see inline for some random thoughts. :) I'm glad you brought this up,
because I need to come up with a solution soon for our internal project
that we are working on so that our developers can write their renderers
correctly.
Simon_Lessard@DMR.CA wrote:
>Hello all,
>
>I raised that issue a while back, but now it's a bit more important since
>I'm trying to finalize ADFFACES-49 issue. What selector synthax do you
>prefer for states:
>1.1. <component>::<subPart>:<state>
>1.2. <component>:<state>::<subPart>.
>
>
We use both syntaxes, and they mean different things.
1.1 means this: The subPart of the component is in this state.
For example:
af|train::stop:disabled (when this train's stop is disabled, then style
the stop like this)
af|train:disabled::stop (when the entire train is disabled, style all
the stops like this)
1.2 means this: The component is in this state, and this is the subpart.
For example:
af|inputText:disabled::content (when the af:inputText disabled="true",
then style the content piece like this)
>I prefer the former and it's easier to implement. However, we already
have
>some :disabled that use the latter synthax.
>
>Secondly, there's also the issue raised by Jeanne, how should we manage
>which states are intercepted and which should pass through and be copied
>in the final CSS:
>2.1. Use a component specific list, so that :disabled could pass through
>for some components but get intercepted for some others? If that solution
>is selected, how/where should we configure that list, in the
>faces-config's metadata?
>
>
I like this one the best because let's say I use :disabled and I
intercept it and do some funky things with it. Then let's say I decide
that the css spec deals
with :disabled perfectly fine, and I don't need to intercept it.
Also, let's say :hover and :active work great on some dom elements, but
do they work for everything?
Let's say I have this: <span class="myText">Hello!</span> and this css:
.myText {color: black}
.myText:hover {color:red}
Does this work? (not in my tests)
But what if this represents a component. I might want them to be able to
specify .myText:hover and have it work even if the built-in browser
support wasn't there.
So I would want
af|myComponent:hover to work.
I'd render this
<span class="af_myComponent p_AFHover">Hello!</span>
when they are hovering over my span.
>2.2. Use a list of pseudo-classes passing through for all components.
Such
>list would have to be based on W3C, but as Jeanne observed, such list
>would break our :disabled that we're intercepting currently and could
lead
>to som.e problems if more pseudo-classes are added in future version of
>CSS.
>
>
Yes, I'd have to change the name of :disabled. But so far that is the
only css valid pseudo-class that I use to date.
We have others like :hover (see above... if we don't want this to pass
through, we'll need to change it to something else).
>2.3. Use a static list of pseudo-classes to intercept used by all
>components? If so, where should we place it? This solution probably has
>the same flaws as 2.2 if a new pseudo-classes i nthe CSS specification
>matches a name defined in the intercept list.
>2.4. Use a prefix for intercepted pseudo-classes like the -ora- used for
>properties?
>
>
I like this second best. If we did this, then I'd suggest that we also
prefix the pseudo-elements.
The problem is, taking my :hover example, some components might be
rendered such that the browser
automatically works with :hover on the generated css, but others don't,
so those that don't have to have
:-tri-hover ?
>
>My votes are:
>+1 for 1.1
>+1 for 2.2, but I would not place states resolvable during rendering in
>that list, so that disabled is still intercepted.
>
>
Re: ADFFACES-49 inputText::content:required or inputText:required::content
Posted by Jeanne Waldman <je...@oracle.com>.
see inline for some random thoughts. :) I'm glad you brought this up,
because I need to come up with a solution soon for our internal project
that we are working on so that our developers can write their renderers
correctly.
Simon_Lessard@DMR.CA wrote:
>Hello all,
>
>I raised that issue a while back, but now it's a bit more important since
>I'm trying to finalize ADFFACES-49 issue. What selector synthax do you
>prefer for states:
>1.1. <component>::<subPart>:<state>
>1.2. <component>:<state>::<subPart>.
>
>
We use both syntaxes, and they mean different things.
1.1 means this: The subPart of the component is in this state.
For example:
af|train::stop:disabled (when this train's stop is disabled, then style
the stop like this)
af|train:disabled::stop (when the entire train is disabled, style all
the stops like this)
1.2 means this: The component is in this state, and this is the subpart.
For example:
af|inputText:disabled::content (when the af:inputText disabled="true",
then style the content piece like this)
>I prefer the former and it's easier to implement. However, we already have
>some :disabled that use the latter synthax.
>
>Secondly, there's also the issue raised by Jeanne, how should we manage
>which states are intercepted and which should pass through and be copied
>in the final CSS:
>2.1. Use a component specific list, so that :disabled could pass through
>for some components but get intercepted for some others? If that solution
>is selected, how/where should we configure that list, in the
>faces-config's metadata?
>
>
I like this one the best because let's say I use :disabled and I
intercept it and do some funky things with it. Then let's say I decide
that the css spec deals
with :disabled perfectly fine, and I don't need to intercept it.
Also, let's say :hover and :active work great on some dom elements, but
do they work for everything?
Let's say I have this: <span class="myText">Hello!</span> and this css:
.myText {color: black}
.myText:hover {color:red}
Does this work? (not in my tests)
But what if this represents a component. I might want them to be able to
specify .myText:hover and have it work even if the built-in browser
support wasn't there.
So I would want
af|myComponent:hover to work.
I'd render this
<span class="af_myComponent p_AFHover">Hello!</span>
when they are hovering over my span.
>2.2. Use a list of pseudo-classes passing through for all components. Such
>list would have to be based on W3C, but as Jeanne observed, such list
>would break our :disabled that we're intercepting currently and could lead
>to som.e problems if more pseudo-classes are added in future version of
>CSS.
>
>
Yes, I'd have to change the name of :disabled. But so far that is the
only css valid pseudo-class that I use to date.
We have others like :hover (see above... if we don't want this to pass
through, we'll need to change it to something else).
>2.3. Use a static list of pseudo-classes to intercept used by all
>components? If so, where should we place it? This solution probably has
>the same flaws as 2.2 if a new pseudo-classes i nthe CSS specification
>matches a name defined in the intercept list.
>2.4. Use a prefix for intercepted pseudo-classes like the -ora- used for
>properties?
>
>
I like this second best. If we did this, then I'd suggest that we also
prefix the pseudo-elements.
The problem is, taking my :hover example, some components might be
rendered such that the browser
automatically works with :hover on the generated css, but others don't,
so those that don't have to have
:-tri-hover ?
>
>My votes are:
>+1 for 1.1
>+1 for 2.2, but I would not place states resolvable during rendering in
>that list, so that disabled is still intercepted.
>
>
ADFFACES-49 inputText::content:required or inputText:required::content
Posted by Si...@DMR.CA.
Hello all,
I raised that issue a while back, but now it's a bit more important since
I'm trying to finalize ADFFACES-49 issue. What selector synthax do you
prefer for states:
1.1. <component>::<subPart>:<state>
1.2. <component>:<state>::<subPart>.
I prefer the former and it's easier to implement. However, we already have
some :disabled that use the latter synthax.
Secondly, there's also the issue raised by Jeanne, how should we manage
which states are intercepted and which should pass through and be copied
in the final CSS:
2.1. Use a component specific list, so that :disabled could pass through
for some components but get intercepted for some others? If that solution
is selected, how/where should we configure that list, in the
faces-config's metadata?
2.2. Use a list of pseudo-classes passing through for all components. Such
list would have to be based on W3C, but as Jeanne observed, such list
would break our :disabled that we're intercepting currently and could lead
to som.e problems if more pseudo-classes are added in future version of
CSS.
2.3. Use a static list of pseudo-classes to intercept used by all
components? If so, where should we place it? This solution probably has
the same flaws as 2.2 if a new pseudo-classes i nthe CSS specification
matches a name defined in the intercept list.
2.4. Use a prefix for intercepted pseudo-classes like the -ora- used for
properties?
My votes are:
+1 for 1.1
+1 for 2.2, but I would not place states resolvable during rendering in
that list, so that disabled is still intercepted.
Re: [Issue] inputNumberSpinbox: endless repeat
Posted by Jeanne Waldman <je...@oracle.com>.
I'm happy you found a bug. :) I'll try to investigate some, too. I use
Firefox mainly.
I wonder if it drops an event that tells it to stop. I wonder if there
should be some fallback that checks if the mouse is up every so often
Thanks,
Jeanne
Adam Winer wrote:
> I'm OK with a JIRA issue right away, just so it's known - in case
> you got called away or busy and never had a chance to investigate,
> we'd still have it tracked.
>
> -- Adam
>
>
>
> On 8/17/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
>
>> I know you'll hate me, but I found a bug in inputNumberSpinbox, but I
>> don't know how I triggered it (useful!). Anyway, it seems that under
>> some
>> circumstances _spinboxRepeat will keep going on forever. It happened
>> only
>> once so far, in Firefox. Once it happen there's no way to stop it.
>> Should
>> I open a JIRA issue for that right away or try to find the reproduction
>> case first?
>>
>> ¬ Simon
>>
>
Re: [Issue] inputNumberSpinbox: endless repeat
Posted by Adam Winer <aw...@gmail.com>.
I'm OK with a JIRA issue right away, just so it's known - in case
you got called away or busy and never had a chance to investigate,
we'd still have it tracked.
-- Adam
On 8/17/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> I know you'll hate me, but I found a bug in inputNumberSpinbox, but I
> don't know how I triggered it (useful!). Anyway, it seems that under some
> circumstances _spinboxRepeat will keep going on forever. It happened only
> once so far, in Firefox. Once it happen there's no way to stop it. Should
> I open a JIRA issue for that right away or try to find the reproduction
> case first?
>
> ¬ Simon
>
Re: Button skinning (was Re: [Proposal] Skin hooks for mouseOver and
onPress)
Posted by Si...@DMR.CA.
I just tested those style classes, they're prety nice.However, I think the
results are better with simply the following
.ButtonCellIE
{
margin: 0px;
padding: 0px;
background-image: url(background.jpg);
}
.ButtonStyleIE
{
background-color: transparent;
}
.ButtonCellFirefox
{
margin: 0px;
padding: 0px;
}
.ButtonStyleFirefox
{
background-image: url(background.jpg);
}
It seems that Firefox supports button background-images natively, it works
even without the cell and the result is better oveall. Sadly div does not
work well.
This solution also has its drawback since you cannot use round borders.
For buttons it might not be a huge issue, but navigationPane might hurt,
especially for tabs. So until we can provide users with an equal
flexibility system for tabs I will be
-1 on removing image package
+1 on removing button dependancy toward image package.
¬ Simon
Jeanne Waldman <je...@oracle.com>
2006-08-17 12:55
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject: Re: Button skinning (was Re: [Proposal] Skin hooks
for mouseOver and onPress)
We had a customer that wanted to put background images on our buttons.
He couldn't do this with our buttons unless they had a container
(I haven't tested this in ages, but I remember that he was right), so what
he did was wrap our command button in a afh:cellFormat and put a
styleClass on both.
The problem was that he couldn't style buttons that were rendered as a
part
of another component, so some of his buttons had a gradient background and
some didn't.
I recommend that we wrap our <button> html tag with
a <div> or something so that the skinner can put background images on the
buttons.
The following is how he skinned the commandButton:
.ButtonCell
{
margin: 0px; padding: 0px;
border-top: 1px solid #afc6d7; border-left: 1px solid #afc6d7;
border-bottom: 1px solid #666666; border-right: 1px solid #666666;
background-repeat: repeat-x; background-position: bottom left;
background-color: #ffffff;
text-align: center;
vertical-align: middle;
background-image:url(/content/static/icons/buttonbg.gif)
}
.ButtonStyle
{
margin: 0px; padding: 2px 4px 2px 4px;
border: 0px;
background-color: transparent;
font: 12px Tahoma, Helvetica, sans-serif;
text-align: center;
vertical-align: middle;
cursor:pointer;
}
<afh:cellFormat styleClass="ButtonCell">
<af:commandButton text="#{webStrings.OK}"
action="#{actions.createFolder}"
styleClass="ButtonStyle"/>
</afh:cellFormat>
Adam Winer wrote:
> Oh, that...
>
> That opens up a new topic: what the heck should we do about
> Trinidad button skinning?
>
> As a little background: ADF Faces had a large image-generation
> subsystem code-named "Tecate" that took text, metadata, and
> other images, and composited them into single images. This
> let us have fancy-looking buttons containing, for example,
> translatable text. Instead of trying to get thousands of button
> images translated (which would have been a nightmare), developers
> just got text translated as normal and Tecate did the heavy lifting
> at runtime.
>
> It was used for more than buttons - tabs and "global buttons" (now
> hint="buttons" on navigationPane) also went through this system.
>
> At a certain point, we decided this was just a bad idea, and that a
> better approach was a straightforward HTML and CSS skinning
> approach. So, most of the code moved away from Tecate.
>
> As of Trinidad, though, buttons were still left on it. And, as a
result,
> we have the large org.apache.myfaces.trinidadinternal.image package -
> and all of the code in there - just for one simple feature.
>
> I'd really like to come up with a simpler button skinning strategy,
> and kill the "image" package altogether. The simplest possible
> strategy is just HTML along the lines of:
>
> <button class="af_commandButton>...</button>
>
> -- Adam
>
>
>
> On 8/17/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
>
>>
>> Unless those exist and are not documented it would not work because the
>> button image is composed of 8 part, one background and one text all
>> merged
>> together in a single image. So using CSS :hover and :active on the 9
>> selectors would not work. Furthermore if I remember well :hover and
>> :active works only for links under IE.
>>
>> Maybe those are managed by the skin already but I never figured it out
>> though. Jeanne, can you confirm please?
>>
>>
>> ¬Simon
>>
>>
>>
>>
>>
>> "Adam Winer" <aw...@gmail.com>
>> 2006-08-16 16:47
>> Please respond to adffaces-dev
>>
>> To: adffaces-dev@incubator.apache.org
>> cc:
>> Subject: Re: [Proposal] Skin hooks for mouseOver and
>> onPress
>>
>>
>> Isn't this just :hover and :active?
>>
>> -- Adam
>>
>>
>> On 8/16/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
>> > Hello all,
>> >
>> > I just had a flashback from my ADF Faces project. In that project we
>> > wanted to use a different image on mouse over event. In the end we
had
>> to
>> > use commandLink with an image and some JavaScript events instead.
>> So my
>> > suggestion about button would be to add skin state hooks for
mouseOver
>> and
>> > mouseDown occuring on buttons to improve their L&F and thus user
>> > experience.
>> >
>> > ¬Simon
>> >
>>
>>
>>
>
Re: My settings.xml
Posted by Mark Yvanovich <ma...@oracle.com>.
Sorry about that, I meant to just send that to Jeanne.
Matthias Wessendorf wrote:
> not really sure, why sb. should use this settings.xml
>
> <proxies>
> <proxy>
> <host>www-proxy.us.oracle.com</host>
> <protocol>http</protocol>
> <port>80</port>
> <nonProxyHosts>*.us.oracle.com</nonProxyHosts>
> <active>true</active>
> </proxy>
> </proxies>
>
>
> On 8/18/06, Mark Yvanovich <ma...@oracle.com> wrote:
>
>> :)
>>
>>
>>
>
>
Re: My settings.xml
Posted by Matthias Wessendorf <ma...@apache.org>.
not really sure, why sb. should use this settings.xml
<proxies>
<proxy>
<host>www-proxy.us.oracle.com</host>
<protocol>http</protocol>
<port>80</port>
<nonProxyHosts>*.us.oracle.com</nonProxyHosts>
<active>true</active>
</proxy>
</proxies>
On 8/18/06, Mark Yvanovich <ma...@oracle.com> wrote:
> :)
>
>
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
My settings.xml
Posted by Mark Yvanovich <ma...@oracle.com>.
:)
Re: Little usability issue with inputNumberSpinbox component
Posted by Jeanne Waldman <je...@oracle.com>.
I'll look into moving that up.
Thanks,
Jeanne
Simon_Lessard@DMR.CA wrote:
>I'm not sure if it will be generalized, but I think the increment arrow is
>a bit hard to hit on the new inputSpinbox component. I believe it would be
>better to place the onmousedown event on the td rather than the anchor
>element.
>
>
>Do you think it would be ok or do you see another potential issue ?
>
>¬ Simon
>
>
>
>
>
>Jeanne Waldman <je...@oracle.com>
>2006-08-17 12:55
>Please respond to adffaces-dev
>
> To: adffaces-dev@incubator.apache.org
> cc:
> Subject: Re: Button skinning (was Re: [Proposal] Skin hooks
>for mouseOver and onPress)
>
>
> We had a customer that wanted to put background images on our buttons.
>He couldn't do this with our buttons unless they had a container
>(I haven't tested this in ages, but I remember that he was right), so what
>he did was wrap our command button in a afh:cellFormat and put a
>styleClass on both.
>The problem was that he couldn't style buttons that were rendered as a
>part
>of another component, so some of his buttons had a gradient background and
>some didn't.
>
>I recommend that we wrap our <button> html tag with
>a <div> or something so that the skinner can put background images on the
>buttons.
>
>The following is how he skinned the commandButton:
>
>
> .ButtonCell
> {
> margin: 0px; padding: 0px;
> border-top: 1px solid #afc6d7; border-left: 1px solid #afc6d7;
> border-bottom: 1px solid #666666; border-right: 1px solid #666666;
> background-repeat: repeat-x; background-position: bottom left;
> background-color: #ffffff;
> text-align: center;
> vertical-align: middle;
> background-image:url(/content/static/icons/buttonbg.gif)
> }
> .ButtonStyle
> {
> margin: 0px; padding: 2px 4px 2px 4px;
> border: 0px;
> background-color: transparent;
> font: 12px Tahoma, Helvetica, sans-serif;
> text-align: center;
> vertical-align: middle;
> cursor:pointer;
> }
>
>
>
> <afh:cellFormat styleClass="ButtonCell">
> <af:commandButton text="#{webStrings.OK}"
> action="#{actions.createFolder}"
> styleClass="ButtonStyle"/>
> </afh:cellFormat>
>
>
>
>Adam Winer wrote:
>
>
>
>>Oh, that...
>>
>>That opens up a new topic: what the heck should we do about
>>Trinidad button skinning?
>>
>>As a little background: ADF Faces had a large image-generation
>>subsystem code-named "Tecate" that took text, metadata, and
>>other images, and composited them into single images. This
>>let us have fancy-looking buttons containing, for example,
>>translatable text. Instead of trying to get thousands of button
>>images translated (which would have been a nightmare), developers
>>just got text translated as normal and Tecate did the heavy lifting
>>at runtime.
>>
>>It was used for more than buttons - tabs and "global buttons" (now
>>hint="buttons" on navigationPane) also went through this system.
>>
>>At a certain point, we decided this was just a bad idea, and that a
>>better approach was a straightforward HTML and CSS skinning
>>approach. So, most of the code moved away from Tecate.
>>
>>As of Trinidad, though, buttons were still left on it. And, as a
>>
>>
>result,
>
>
>>we have the large org.apache.myfaces.trinidadinternal.image package -
>>and all of the code in there - just for one simple feature.
>>
>>I'd really like to come up with a simpler button skinning strategy,
>>and kill the "image" package altogether. The simplest possible
>>strategy is just HTML along the lines of:
>>
>> <button class="af_commandButton>...</button>
>>
>>-- Adam
>>
>>
>>
>>On 8/17/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
>>
>>
>>
>>>Unless those exist and are not documented it would not work because the
>>>button image is composed of 8 part, one background and one text all
>>>merged
>>>together in a single image. So using CSS :hover and :active on the 9
>>>selectors would not work. Furthermore if I remember well :hover and
>>>:active works only for links under IE.
>>>
>>>Maybe those are managed by the skin already but I never figured it out
>>>though. Jeanne, can you confirm please?
>>>
>>>
>>>¬Simon
>>>
>>>
>>>
>>>
>>>
>>>"Adam Winer" <aw...@gmail.com>
>>>2006-08-16 16:47
>>>Please respond to adffaces-dev
>>>
>>> To: adffaces-dev@incubator.apache.org
>>> cc:
>>> Subject: Re: [Proposal] Skin hooks for mouseOver and
>>>onPress
>>>
>>>
>>>Isn't this just :hover and :active?
>>>
>>>-- Adam
>>>
>>>
>>>On 8/16/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
>>>
>>>
>>>>Hello all,
>>>>
>>>>I just had a flashback from my ADF Faces project. In that project we
>>>>wanted to use a different image on mouse over event. In the end we
>>>>
>>>>
>had
>
>
>>>to
>>>
>>>
>>>>use commandLink with an image and some JavaScript events instead.
>>>>
>>>>
>>>So my
>>>
>>>
>>>>suggestion about button would be to add skin state hooks for
>>>>
>>>>
>mouseOver
>
>
>>>and
>>>
>>>
>>>>mouseDown occuring on buttons to improve their L&F and thus user
>>>>experience.
>>>>
>>>>¬Simon
>>>>
>>>>
>>>>
>>>
>>>
>>>
>
>
>
>
>
Little usability issue with inputNumberSpinbox component
Posted by Si...@DMR.CA.
I'm not sure if it will be generalized, but I think the increment arrow is
a bit hard to hit on the new inputSpinbox component. I believe it would be
better to place the onmousedown event on the td rather than the anchor
element.
Do you think it would be ok or do you see another potential issue ?
¬ Simon
Jeanne Waldman <je...@oracle.com>
2006-08-17 12:55
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject: Re: Button skinning (was Re: [Proposal] Skin hooks
for mouseOver and onPress)
We had a customer that wanted to put background images on our buttons.
He couldn't do this with our buttons unless they had a container
(I haven't tested this in ages, but I remember that he was right), so what
he did was wrap our command button in a afh:cellFormat and put a
styleClass on both.
The problem was that he couldn't style buttons that were rendered as a
part
of another component, so some of his buttons had a gradient background and
some didn't.
I recommend that we wrap our <button> html tag with
a <div> or something so that the skinner can put background images on the
buttons.
The following is how he skinned the commandButton:
.ButtonCell
{
margin: 0px; padding: 0px;
border-top: 1px solid #afc6d7; border-left: 1px solid #afc6d7;
border-bottom: 1px solid #666666; border-right: 1px solid #666666;
background-repeat: repeat-x; background-position: bottom left;
background-color: #ffffff;
text-align: center;
vertical-align: middle;
background-image:url(/content/static/icons/buttonbg.gif)
}
.ButtonStyle
{
margin: 0px; padding: 2px 4px 2px 4px;
border: 0px;
background-color: transparent;
font: 12px Tahoma, Helvetica, sans-serif;
text-align: center;
vertical-align: middle;
cursor:pointer;
}
<afh:cellFormat styleClass="ButtonCell">
<af:commandButton text="#{webStrings.OK}"
action="#{actions.createFolder}"
styleClass="ButtonStyle"/>
</afh:cellFormat>
Adam Winer wrote:
> Oh, that...
>
> That opens up a new topic: what the heck should we do about
> Trinidad button skinning?
>
> As a little background: ADF Faces had a large image-generation
> subsystem code-named "Tecate" that took text, metadata, and
> other images, and composited them into single images. This
> let us have fancy-looking buttons containing, for example,
> translatable text. Instead of trying to get thousands of button
> images translated (which would have been a nightmare), developers
> just got text translated as normal and Tecate did the heavy lifting
> at runtime.
>
> It was used for more than buttons - tabs and "global buttons" (now
> hint="buttons" on navigationPane) also went through this system.
>
> At a certain point, we decided this was just a bad idea, and that a
> better approach was a straightforward HTML and CSS skinning
> approach. So, most of the code moved away from Tecate.
>
> As of Trinidad, though, buttons were still left on it. And, as a
result,
> we have the large org.apache.myfaces.trinidadinternal.image package -
> and all of the code in there - just for one simple feature.
>
> I'd really like to come up with a simpler button skinning strategy,
> and kill the "image" package altogether. The simplest possible
> strategy is just HTML along the lines of:
>
> <button class="af_commandButton>...</button>
>
> -- Adam
>
>
>
> On 8/17/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
>
>>
>> Unless those exist and are not documented it would not work because the
>> button image is composed of 8 part, one background and one text all
>> merged
>> together in a single image. So using CSS :hover and :active on the 9
>> selectors would not work. Furthermore if I remember well :hover and
>> :active works only for links under IE.
>>
>> Maybe those are managed by the skin already but I never figured it out
>> though. Jeanne, can you confirm please?
>>
>>
>> ¬Simon
>>
>>
>>
>>
>>
>> "Adam Winer" <aw...@gmail.com>
>> 2006-08-16 16:47
>> Please respond to adffaces-dev
>>
>> To: adffaces-dev@incubator.apache.org
>> cc:
>> Subject: Re: [Proposal] Skin hooks for mouseOver and
>> onPress
>>
>>
>> Isn't this just :hover and :active?
>>
>> -- Adam
>>
>>
>> On 8/16/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
>> > Hello all,
>> >
>> > I just had a flashback from my ADF Faces project. In that project we
>> > wanted to use a different image on mouse over event. In the end we
had
>> to
>> > use commandLink with an image and some JavaScript events instead.
>> So my
>> > suggestion about button would be to add skin state hooks for
mouseOver
>> and
>> > mouseDown occuring on buttons to improve their L&F and thus user
>> > experience.
>> >
>> > ¬Simon
>> >
>>
>>
>>
>
[Issue] inputNumberSpinbox: endless repeat
Posted by Si...@DMR.CA.
I know you'll hate me, but I found a bug in inputNumberSpinbox, but I
don't know how I triggered it (useful!). Anyway, it seems that under some
circumstances _spinboxRepeat will keep going on forever. It happened only
once so far, in Firefox. Once it happen there's no way to stop it. Should
I open a JIRA issue for that right away or try to find the reproduction
case first?
¬ Simon
Re: XSS format question
Posted by Jeanne Waldman <je...@oracle.com>.
I'd have to try it to refresh my memory, but I think that should work.
Does it? :)
The named styles are equivalent to css aliases. They are never written
out to the generated css file.
- Jeanne
Simon_Lessard@DMR.CA wrote:
>Hello all,
>
>I'm working on ADFFACES-49 and while playing with base-desktop.xss I saw
>there's two type of styles, those named and those with a selector. I
>assume those named are equivalent to CSS aliases? Also, is it possible to
>include a style that is not named? More specifically, I would like to have
>something like this for required labels:
>
> <style selector="af|inputColor::required::label">
> <includeStyle selector="af|inputColor::label"/>
> <includeStyle name="AFRequiredLabel"/>
> </style>
>
>Is that correct?
>
>¬ Simon
>
>
>
>
>Jeanne Waldman <je...@oracle.com>
>2006-08-17 12:55
>Please respond to adffaces-dev
>
> To: adffaces-dev@incubator.apache.org
> cc:
> Subject: Re: Button skinning (was Re: [Proposal] Skin hooks
>for mouseOver and onPress)
>
>
> We had a customer that wanted to put background images on our buttons.
>He couldn't do this with our buttons unless they had a container
>(I haven't tested this in ages, but I remember that he was right), so what
>he did was wrap our command button in a afh:cellFormat and put a
>styleClass on both.
>The problem was that he couldn't style buttons that were rendered as a
>part
>of another component, so some of his buttons had a gradient background and
>some didn't.
>
>I recommend that we wrap our <button> html tag with
>a <div> or something so that the skinner can put background images on the
>buttons.
>
>The following is how he skinned the commandButton:
>
>
> .ButtonCell
> {
> margin: 0px; padding: 0px;
> border-top: 1px solid #afc6d7; border-left: 1px solid #afc6d7;
> border-bottom: 1px solid #666666; border-right: 1px solid #666666;
> background-repeat: repeat-x; background-position: bottom left;
> background-color: #ffffff;
> text-align: center;
> vertical-align: middle;
> background-image:url(/content/static/icons/buttonbg.gif)
> }
> .ButtonStyle
> {
> margin: 0px; padding: 2px 4px 2px 4px;
> border: 0px;
> background-color: transparent;
> font: 12px Tahoma, Helvetica, sans-serif;
> text-align: center;
> vertical-align: middle;
> cursor:pointer;
> }
>
>
>
> <afh:cellFormat styleClass="ButtonCell">
> <af:commandButton text="#{webStrings.OK}"
> action="#{actions.createFolder}"
> styleClass="ButtonStyle"/>
> </afh:cellFormat>
>
>
>
>Adam Winer wrote:
>
>
>
>>Oh, that...
>>
>>That opens up a new topic: what the heck should we do about
>>Trinidad button skinning?
>>
>>As a little background: ADF Faces had a large image-generation
>>subsystem code-named "Tecate" that took text, metadata, and
>>other images, and composited them into single images. This
>>let us have fancy-looking buttons containing, for example,
>>translatable text. Instead of trying to get thousands of button
>>images translated (which would have been a nightmare), developers
>>just got text translated as normal and Tecate did the heavy lifting
>>at runtime.
>>
>>It was used for more than buttons - tabs and "global buttons" (now
>>hint="buttons" on navigationPane) also went through this system.
>>
>>At a certain point, we decided this was just a bad idea, and that a
>>better approach was a straightforward HTML and CSS skinning
>>approach. So, most of the code moved away from Tecate.
>>
>>As of Trinidad, though, buttons were still left on it. And, as a
>>
>>
>result,
>
>
>>we have the large org.apache.myfaces.trinidadinternal.image package -
>>and all of the code in there - just for one simple feature.
>>
>>I'd really like to come up with a simpler button skinning strategy,
>>and kill the "image" package altogether. The simplest possible
>>strategy is just HTML along the lines of:
>>
>> <button class="af_commandButton>...</button>
>>
>>-- Adam
>>
>>
>>
>>On 8/17/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
>>
>>
>>
>>>Unless those exist and are not documented it would not work because the
>>>button image is composed of 8 part, one background and one text all
>>>merged
>>>together in a single image. So using CSS :hover and :active on the 9
>>>selectors would not work. Furthermore if I remember well :hover and
>>>:active works only for links under IE.
>>>
>>>Maybe those are managed by the skin already but I never figured it out
>>>though. Jeanne, can you confirm please?
>>>
>>>
>>>¬Simon
>>>
>>>
>>>
>>>
>>>
>>>"Adam Winer" <aw...@gmail.com>
>>>2006-08-16 16:47
>>>Please respond to adffaces-dev
>>>
>>> To: adffaces-dev@incubator.apache.org
>>> cc:
>>> Subject: Re: [Proposal] Skin hooks for mouseOver and
>>>onPress
>>>
>>>
>>>Isn't this just :hover and :active?
>>>
>>>-- Adam
>>>
>>>
>>>On 8/16/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
>>>
>>>
>>>>Hello all,
>>>>
>>>>I just had a flashback from my ADF Faces project. In that project we
>>>>wanted to use a different image on mouse over event. In the end we
>>>>
>>>>
>had
>
>
>>>to
>>>
>>>
>>>>use commandLink with an image and some JavaScript events instead.
>>>>
>>>>
>>>So my
>>>
>>>
>>>>suggestion about button would be to add skin state hooks for
>>>>
>>>>
>mouseOver
>
>
>>>and
>>>
>>>
>>>>mouseDown occuring on buttons to improve their L&F and thus user
>>>>experience.
>>>>
>>>>¬Simon
>>>>
>>>>
>>>>
>>>
>>>
>>>
>
>
>
>
>
XSS format question
Posted by Si...@DMR.CA.
Hello all,
I'm working on ADFFACES-49 and while playing with base-desktop.xss I saw
there's two type of styles, those named and those with a selector. I
assume those named are equivalent to CSS aliases? Also, is it possible to
include a style that is not named? More specifically, I would like to have
something like this for required labels:
<style selector="af|inputColor::required::label">
<includeStyle selector="af|inputColor::label"/>
<includeStyle name="AFRequiredLabel"/>
</style>
Is that correct?
¬ Simon
Jeanne Waldman <je...@oracle.com>
2006-08-17 12:55
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject: Re: Button skinning (was Re: [Proposal] Skin hooks
for mouseOver and onPress)
We had a customer that wanted to put background images on our buttons.
He couldn't do this with our buttons unless they had a container
(I haven't tested this in ages, but I remember that he was right), so what
he did was wrap our command button in a afh:cellFormat and put a
styleClass on both.
The problem was that he couldn't style buttons that were rendered as a
part
of another component, so some of his buttons had a gradient background and
some didn't.
I recommend that we wrap our <button> html tag with
a <div> or something so that the skinner can put background images on the
buttons.
The following is how he skinned the commandButton:
.ButtonCell
{
margin: 0px; padding: 0px;
border-top: 1px solid #afc6d7; border-left: 1px solid #afc6d7;
border-bottom: 1px solid #666666; border-right: 1px solid #666666;
background-repeat: repeat-x; background-position: bottom left;
background-color: #ffffff;
text-align: center;
vertical-align: middle;
background-image:url(/content/static/icons/buttonbg.gif)
}
.ButtonStyle
{
margin: 0px; padding: 2px 4px 2px 4px;
border: 0px;
background-color: transparent;
font: 12px Tahoma, Helvetica, sans-serif;
text-align: center;
vertical-align: middle;
cursor:pointer;
}
<afh:cellFormat styleClass="ButtonCell">
<af:commandButton text="#{webStrings.OK}"
action="#{actions.createFolder}"
styleClass="ButtonStyle"/>
</afh:cellFormat>
Adam Winer wrote:
> Oh, that...
>
> That opens up a new topic: what the heck should we do about
> Trinidad button skinning?
>
> As a little background: ADF Faces had a large image-generation
> subsystem code-named "Tecate" that took text, metadata, and
> other images, and composited them into single images. This
> let us have fancy-looking buttons containing, for example,
> translatable text. Instead of trying to get thousands of button
> images translated (which would have been a nightmare), developers
> just got text translated as normal and Tecate did the heavy lifting
> at runtime.
>
> It was used for more than buttons - tabs and "global buttons" (now
> hint="buttons" on navigationPane) also went through this system.
>
> At a certain point, we decided this was just a bad idea, and that a
> better approach was a straightforward HTML and CSS skinning
> approach. So, most of the code moved away from Tecate.
>
> As of Trinidad, though, buttons were still left on it. And, as a
result,
> we have the large org.apache.myfaces.trinidadinternal.image package -
> and all of the code in there - just for one simple feature.
>
> I'd really like to come up with a simpler button skinning strategy,
> and kill the "image" package altogether. The simplest possible
> strategy is just HTML along the lines of:
>
> <button class="af_commandButton>...</button>
>
> -- Adam
>
>
>
> On 8/17/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
>
>>
>> Unless those exist and are not documented it would not work because the
>> button image is composed of 8 part, one background and one text all
>> merged
>> together in a single image. So using CSS :hover and :active on the 9
>> selectors would not work. Furthermore if I remember well :hover and
>> :active works only for links under IE.
>>
>> Maybe those are managed by the skin already but I never figured it out
>> though. Jeanne, can you confirm please?
>>
>>
>> ¬Simon
>>
>>
>>
>>
>>
>> "Adam Winer" <aw...@gmail.com>
>> 2006-08-16 16:47
>> Please respond to adffaces-dev
>>
>> To: adffaces-dev@incubator.apache.org
>> cc:
>> Subject: Re: [Proposal] Skin hooks for mouseOver and
>> onPress
>>
>>
>> Isn't this just :hover and :active?
>>
>> -- Adam
>>
>>
>> On 8/16/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
>> > Hello all,
>> >
>> > I just had a flashback from my ADF Faces project. In that project we
>> > wanted to use a different image on mouse over event. In the end we
had
>> to
>> > use commandLink with an image and some JavaScript events instead.
>> So my
>> > suggestion about button would be to add skin state hooks for
mouseOver
>> and
>> > mouseDown occuring on buttons to improve their L&F and thus user
>> > experience.
>> >
>> > ¬Simon
>> >
>>
>>
>>
>
Re: Button skinning (was Re: [Proposal] Skin hooks for mouseOver
and onPress)
Posted by Jeanne Waldman <je...@oracle.com>.
We had a customer that wanted to put background images on our buttons.
He couldn't do this with our buttons unless they had a container
(I haven't tested this in ages, but I remember that he was right), so what
he did was wrap our command button in a afh:cellFormat and put a styleClass on both.
The problem was that he couldn't style buttons that were rendered as a part
of another component, so some of his buttons had a gradient background and some didn't.
I recommend that we wrap our <button> html tag with
a <div> or something so that the skinner can put background images on the buttons.
The following is how he skinned the commandButton:
.ButtonCell
{
margin: 0px; padding: 0px;
border-top: 1px solid #afc6d7; border-left: 1px solid #afc6d7;
border-bottom: 1px solid #666666; border-right: 1px solid #666666;
background-repeat: repeat-x; background-position: bottom left;
background-color: #ffffff;
text-align: center;
vertical-align: middle;
background-image:url(/content/static/icons/buttonbg.gif)
}
.ButtonStyle
{
margin: 0px; padding: 2px 4px 2px 4px;
border: 0px;
background-color: transparent;
font: 12px Tahoma, Helvetica, sans-serif;
text-align: center;
vertical-align: middle;
cursor:pointer;
}
<afh:cellFormat styleClass="ButtonCell">
<af:commandButton text="#{webStrings.OK}"
action="#{actions.createFolder}"
styleClass="ButtonStyle"/>
</afh:cellFormat>
Adam Winer wrote:
> Oh, that...
>
> That opens up a new topic: what the heck should we do about
> Trinidad button skinning?
>
> As a little background: ADF Faces had a large image-generation
> subsystem code-named "Tecate" that took text, metadata, and
> other images, and composited them into single images. This
> let us have fancy-looking buttons containing, for example,
> translatable text. Instead of trying to get thousands of button
> images translated (which would have been a nightmare), developers
> just got text translated as normal and Tecate did the heavy lifting
> at runtime.
>
> It was used for more than buttons - tabs and "global buttons" (now
> hint="buttons" on navigationPane) also went through this system.
>
> At a certain point, we decided this was just a bad idea, and that a
> better approach was a straightforward HTML and CSS skinning
> approach. So, most of the code moved away from Tecate.
>
> As of Trinidad, though, buttons were still left on it. And, as a result,
> we have the large org.apache.myfaces.trinidadinternal.image package -
> and all of the code in there - just for one simple feature.
>
> I'd really like to come up with a simpler button skinning strategy,
> and kill the "image" package altogether. The simplest possible
> strategy is just HTML along the lines of:
>
> <button class="af_commandButton>...</button>
>
> -- Adam
>
>
>
> On 8/17/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
>
>>
>> Unless those exist and are not documented it would not work because the
>> button image is composed of 8 part, one background and one text all
>> merged
>> together in a single image. So using CSS :hover and :active on the 9
>> selectors would not work. Furthermore if I remember well :hover and
>> :active works only for links under IE.
>>
>> Maybe those are managed by the skin already but I never figured it out
>> though. Jeanne, can you confirm please?
>>
>>
>> ¬Simon
>>
>>
>>
>>
>>
>> "Adam Winer" <aw...@gmail.com>
>> 2006-08-16 16:47
>> Please respond to adffaces-dev
>>
>> To: adffaces-dev@incubator.apache.org
>> cc:
>> Subject: Re: [Proposal] Skin hooks for mouseOver and
>> onPress
>>
>>
>> Isn't this just :hover and :active?
>>
>> -- Adam
>>
>>
>> On 8/16/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
>> > Hello all,
>> >
>> > I just had a flashback from my ADF Faces project. In that project we
>> > wanted to use a different image on mouse over event. In the end we had
>> to
>> > use commandLink with an image and some JavaScript events instead.
>> So my
>> > suggestion about button would be to add skin state hooks for mouseOver
>> and
>> > mouseDown occuring on buttons to improve their L&F and thus user
>> > experience.
>> >
>> > ¬Simon
>> >
>>
>>
>>
>