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 Si...@DMR.CA on 2006/08/14 12:29:15 UTC
[Issue] Compilation error as of 2006-08-14 8h29 a.m. EST
Hello,
Compilation of current Trinidad version fails because of tearDown and
setUp method overriding. Should I look into it or another patch for test
classes is already on the way?
Regards,
Simon Lessard
Fujitsu Consulting
Re: ADFFACES-85
Posted by Si...@DMR.CA.
Sure!
Simon Lessard
Fujitsu Consulting
"Adam Winer" <aw...@gmail.com>
2006-08-14 12:05
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject: Re: ADFFACES-85
Ah, looks like it is done. Could you do two things?
- Close the issue with this solution
- Start a skinning how-to Wiki page, also including this solution?
Thanks!
This reminds me: I need to check internally (at Oracle) whether some
of the other ideas we had for changing up output to improve
skinnability (esp. of the input components) made it in to the
Trinidad codebase or not, and if not see about getting some proposals
brought forward for them.
-- Adam Winer
On 8/14/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> Hello,
>
> I retested this issue using latest build, and the behavior is different
> from old ADF Faces. Basically you can add input field spacing using
> something like the following
>
> af|panelFormLayout::label-cell
> {
> padding-top: 10px;
> vertical-align: top;
> }
>
> af|panelFormLayout::content-cell
> {
> padding-top: 8px;
> }
>
> Should the issue be closed, or a new selector for rows inside panel form
> would still be desirable?
>
>
> Regards,
>
> Simon Lessard
> Fujitsu Consulting
>
Re: ADFFACES-85
Posted by Adam Winer <aw...@gmail.com>.
Ah, looks like it is done. Could you do two things?
- Close the issue with this solution
- Start a skinning how-to Wiki page, also including this solution?
Thanks!
This reminds me: I need to check internally (at Oracle) whether some
of the other ideas we had for changing up output to improve
skinnability (esp. of the input components) made it in to the
Trinidad codebase or not, and if not see about getting some proposals
brought forward for them.
-- Adam Winer
On 8/14/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> Hello,
>
> I retested this issue using latest build, and the behavior is different
> from old ADF Faces. Basically you can add input field spacing using
> something like the following
>
> af|panelFormLayout::label-cell
> {
> padding-top: 10px;
> vertical-align: top;
> }
>
> af|panelFormLayout::content-cell
> {
> padding-top: 8px;
> }
>
> Should the issue be closed, or a new selector for rows inside panel form
> would still be desirable?
>
>
> Regards,
>
> Simon Lessard
> Fujitsu Consulting
>
ADFFACES-85
Posted by Si...@DMR.CA.
Hello,
I retested this issue using latest build, and the behavior is different
from old ADF Faces. Basically you can add input field spacing using
something like the following
af|panelFormLayout::label-cell
{
padding-top: 10px;
vertical-align: top;
}
af|panelFormLayout::content-cell
{
padding-top: 8px;
}
Should the issue be closed, or a new selector for rows inside panel form
would still be desirable?
Regards,
Simon Lessard
Fujitsu Consulting
Re: [Issue] Compilation error as of 2006-08-14 8h29 a.m. EST
Posted by Si...@DMR.CA.
Hmmmm,
I actually did an update this morning before trying to compile. I'm dumb,
but not that much... yet. Continuum also flag a compilation error btw. My
teammate also have the compilation error. I already patched my local
version using two replace all in files though.
Regards,
Simon Lessard
Fujitsu Consulting
"Craig McClanahan" <cr...@apache.org>
Sent by: craigmcc@gmail.com
2006-08-14 10:51
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject: Re: [Issue] Compilation error as of 2006-08-14
8h29 a.m. EST
On 8/14/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
>
> Hello,
>
> Compilation of current Trinidad version fails because of tearDown and
> setUp method overriding. Should I look into it or another patch for test
> classes is already on the way?
I checked in a patch for this on Saturday, and it compiles for me. You'll
need the latest source code to deal with this.
Regards,
>
> Simon Lessard
> Fujitsu Consulting
>
Craig
Re: Re: [Issue] Compilation error as of 2006-08-14 8h29 a.m. EST
Posted by Matthias Wessendorf <ma...@apache.org>.
yeah,
I am not sure why you have to do that. In my old company we had
lot's of issues with that (maven1). So, if something *should* be different...
I kill something in the repo ...
On 8/14/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> Killing shale directory did the trick for me.
>
>
> Thanks,
>
> Simon Lessard
> Fujitsu Consulting
>
>
>
>
>
> "Matthias Wessendorf" <ma...@apache.org>
> Sent by: mwessendorf@gmail.com
> 2006-08-14 15:22
> Please respond to adffaces-dev
>
> To: adffaces-dev@incubator.apache.org
> cc:
> Subject: Re: Re: [Issue] Compilation error as of 2006-08-14
> 8h29 a.m. EST
>
>
> It worked for me.
>
> kill your org.apache.shale folder in the m2_repo
>
> the correct JAR is public
>
>
> On 8/14/06, Craig McClanahan <cr...@apache.org> wrote:
> > On 8/14/06, Adam Winer <aw...@gmail.com> wrote:
> > >
> > > Is the latest Shale code out on the snapshot repository?
> >
> >
> > Yes, in the Apache snapshot repository (version 1.0.3-SNAPSHOT is
> updated by
> > the nightly builds).
> >
> > -- Adam
> >
> >
> > Craig
> >
> > On 8/14/06, Craig McClanahan <cr...@apache.org> wrote:
> > > > On 8/14/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > Compilation of current Trinidad version fails because of tearDown
> and
> > > > > setUp method overriding. Should I look into it or another patch
> for
> > > test
> > > > > classes is already on the way?
> > > >
> > > >
> > > > I checked in a patch for this on Saturday, and it compiles for
> > > me. You'll
> > > > need the latest source code to deal with this.
> > > >
> > > > Regards,
> > > > >
> > > > > Simon Lessard
> > > > > Fujitsu Consulting
> > > > >
> > > >
> > > >
> > > > Craig
> > > >
> > > >
> > >
> >
> >
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
>
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: Re: [Issue] Compilation error as of 2006-08-14 8h29 a.m. EST
Posted by Adam Winer <aw...@gmail.com>.
My understanding is that:
- Maven 1 checked for newer versions of snapshots every build.
- Maven 2 checks, by default, once a day, but can be forced
to check explicitly (I don't know how, though).
There's a -U option on Maven 2 to forcibly download new
versions, but that applies to *everything* not just snapshots,
so you'll download new versions of any plugin or report you use,
etc., which can be destabilizing.
-- Adam
On 8/14/06, Craig McClanahan <cr...@apache.org> wrote:
>
> On 8/14/06, Matthias Wessendorf <ma...@apache.org> wrote:
> >
> > It worked for me.
> >
> > kill your org.apache.shale folder in the m2_repo
> >
> > the correct JAR is public
>
>
> Hmm ... does that not imply that Maven's "timestamp based" checks for
> downloading later snapshots is not working? The JAR in question is still
> "
> 1.0.3-SNAPSHOT" but I understood Maven treated snapshots specially and
> checked for updates automatically.
>
> Craig
>
> On 8/14/06, Craig McClanahan <cr...@apache.org> wrote:
> > > On 8/14/06, Adam Winer <aw...@gmail.com> wrote:
> > > >
> > > > Is the latest Shale code out on the snapshot repository?
> > >
> > >
> > > Yes, in the Apache snapshot repository (version 1.0.3-SNAPSHOT is
> > updated by
> > > the nightly builds).
> > >
> > > -- Adam
> > >
> > >
> > > Craig
> > >
> > > On 8/14/06, Craig McClanahan <cr...@apache.org> wrote:
> > > > > On 8/14/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > Compilation of current Trinidad version fails because of
> tearDown
> > and
> > > > > > setUp method overriding. Should I look into it or another patch
> > for
> > > > test
> > > > > > classes is already on the way?
> > > > >
> > > > >
> > > > > I checked in a patch for this on Saturday, and it compiles for
> > > > me. You'll
> > > > > need the latest source code to deal with this.
> > > > >
> > > > > Regards,
> > > > > >
> > > > > > Simon Lessard
> > > > > > Fujitsu Consulting
> > > > > >
> > > > >
> > > > >
> > > > > Craig
> > > > >
> > > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > further stuff:
> > blog: http://jroller.com/page/mwessendorf
> > mail: mwessendorf-at-gmail-dot-com
> >
>
>
Re: Re: [Issue] Compilation error as of 2006-08-14 8h29 a.m. EST
Posted by Craig McClanahan <cr...@apache.org>.
On 8/14/06, Matthias Wessendorf <ma...@apache.org> wrote:
>
> It worked for me.
>
> kill your org.apache.shale folder in the m2_repo
>
> the correct JAR is public
Hmm ... does that not imply that Maven's "timestamp based" checks for
downloading later snapshots is not working? The JAR in question is still "
1.0.3-SNAPSHOT" but I understood Maven treated snapshots specially and
checked for updates automatically.
Craig
On 8/14/06, Craig McClanahan <cr...@apache.org> wrote:
> > On 8/14/06, Adam Winer <aw...@gmail.com> wrote:
> > >
> > > Is the latest Shale code out on the snapshot repository?
> >
> >
> > Yes, in the Apache snapshot repository (version 1.0.3-SNAPSHOT is
> updated by
> > the nightly builds).
> >
> > -- Adam
> >
> >
> > Craig
> >
> > On 8/14/06, Craig McClanahan <cr...@apache.org> wrote:
> > > > On 8/14/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > Compilation of current Trinidad version fails because of tearDown
> and
> > > > > setUp method overriding. Should I look into it or another patch
> for
> > > test
> > > > > classes is already on the way?
> > > >
> > > >
> > > > I checked in a patch for this on Saturday, and it compiles for
> > > me. You'll
> > > > need the latest source code to deal with this.
> > > >
> > > > Regards,
> > > > >
> > > > > Simon Lessard
> > > > > Fujitsu Consulting
> > > > >
> > > >
> > > >
> > > > Craig
> > > >
> > > >
> > >
> >
> >
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
Re: Re: [Issue] Compilation error as of 2006-08-14 8h29 a.m. EST
Posted by Si...@DMR.CA.
Killing shale directory did the trick for me.
Thanks,
Simon Lessard
Fujitsu Consulting
"Matthias Wessendorf" <ma...@apache.org>
Sent by: mwessendorf@gmail.com
2006-08-14 15:22
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject: Re: Re: [Issue] Compilation error as of 2006-08-14
8h29 a.m. EST
It worked for me.
kill your org.apache.shale folder in the m2_repo
the correct JAR is public
On 8/14/06, Craig McClanahan <cr...@apache.org> wrote:
> On 8/14/06, Adam Winer <aw...@gmail.com> wrote:
> >
> > Is the latest Shale code out on the snapshot repository?
>
>
> Yes, in the Apache snapshot repository (version 1.0.3-SNAPSHOT is
updated by
> the nightly builds).
>
> -- Adam
>
>
> Craig
>
> On 8/14/06, Craig McClanahan <cr...@apache.org> wrote:
> > > On 8/14/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> > > >
> > > > Hello,
> > > >
> > > > Compilation of current Trinidad version fails because of tearDown
and
> > > > setUp method overriding. Should I look into it or another patch
for
> > test
> > > > classes is already on the way?
> > >
> > >
> > > I checked in a patch for this on Saturday, and it compiles for
> > me. You'll
> > > need the latest source code to deal with this.
> > >
> > > Regards,
> > > >
> > > > Simon Lessard
> > > > Fujitsu Consulting
> > > >
> > >
> > >
> > > Craig
> > >
> > >
> >
>
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: Re: [Issue] Compilation error as of 2006-08-14 8h29 a.m. EST
Posted by Matthias Wessendorf <ma...@apache.org>.
It worked for me.
kill your org.apache.shale folder in the m2_repo
the correct JAR is public
On 8/14/06, Craig McClanahan <cr...@apache.org> wrote:
> On 8/14/06, Adam Winer <aw...@gmail.com> wrote:
> >
> > Is the latest Shale code out on the snapshot repository?
>
>
> Yes, in the Apache snapshot repository (version 1.0.3-SNAPSHOT is updated by
> the nightly builds).
>
> -- Adam
>
>
> Craig
>
> On 8/14/06, Craig McClanahan <cr...@apache.org> wrote:
> > > On 8/14/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> > > >
> > > > Hello,
> > > >
> > > > Compilation of current Trinidad version fails because of tearDown and
> > > > setUp method overriding. Should I look into it or another patch for
> > test
> > > > classes is already on the way?
> > >
> > >
> > > I checked in a patch for this on Saturday, and it compiles for
> > me. You'll
> > > need the latest source code to deal with this.
> > >
> > > Regards,
> > > >
> > > > Simon Lessard
> > > > Fujitsu Consulting
> > > >
> > >
> > >
> > > Craig
> > >
> > >
> >
>
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: Re: [Issue] Compilation error as of 2006-08-14 8h29 a.m. EST
Posted by Craig McClanahan <cr...@apache.org>.
On 8/14/06, Adam Winer <aw...@gmail.com> wrote:
>
> Is the latest Shale code out on the snapshot repository?
Yes, in the Apache snapshot repository (version 1.0.3-SNAPSHOT is updated by
the nightly builds).
-- Adam
Craig
On 8/14/06, Craig McClanahan <cr...@apache.org> wrote:
> > On 8/14/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> > >
> > > Hello,
> > >
> > > Compilation of current Trinidad version fails because of tearDown and
> > > setUp method overriding. Should I look into it or another patch for
> test
> > > classes is already on the way?
> >
> >
> > I checked in a patch for this on Saturday, and it compiles for
> me. You'll
> > need the latest source code to deal with this.
> >
> > Regards,
> > >
> > > Simon Lessard
> > > Fujitsu Consulting
> > >
> >
> >
> > Craig
> >
> >
>
Re: Re: [Issue] Compilation error as of 2006-08-14 8h29 a.m. EST
Posted by Adam Winer <aw...@gmail.com>.
Is the latest Shale code out on the snapshot repository?
-- Adam
On 8/14/06, Craig McClanahan <cr...@apache.org> wrote:
> On 8/14/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> >
> > Hello,
> >
> > Compilation of current Trinidad version fails because of tearDown and
> > setUp method overriding. Should I look into it or another patch for test
> > classes is already on the way?
>
>
> I checked in a patch for this on Saturday, and it compiles for me. You'll
> need the latest source code to deal with this.
>
> Regards,
> >
> > Simon Lessard
> > Fujitsu Consulting
> >
>
>
> Craig
>
>
Re: [Issue] Compilation error as of 2006-08-14 8h29 a.m. EST
Posted by Craig McClanahan <cr...@apache.org>.
On 8/14/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
>
> Hello,
>
> Compilation of current Trinidad version fails because of tearDown and
> setUp method overriding. Should I look into it or another patch for test
> classes is already on the way?
I checked in a patch for this on Saturday, and it compiles for me. You'll
need the latest source code to deal with this.
Regards,
>
> Simon Lessard
> Fujitsu Consulting
>
Craig
Re: [Proposal] Skin: Convert url values to context relative path
only when enclosed in url( )
Posted by Jeanne Waldman <je...@oracle.com>.
+1 to Convert url(); anything other than than this syntax gets dropped
and logged with a warning
Adam Winer wrote:
> The spec - http://www.w3.org/TR/CSS21/syndata.html#value-def-uri -
> seems clear that url() is required (though quotes are not required).
> I'd favor an option #3:
> - Convert url(); anything other than than this syntax gets dropped
> and logged with a warning
>
> But we should talk about the manner of URL conversion here; IMO,
> the rules should be:
>
> - URLs beginning with a slash get prefixed with the context root
> (like other such URLs in JSF)
> - URLs beginning with two slashes get trimmed to a single slash
> (special Trinidad URL rule, already used in Trinidad components)
> - Relative URLs get interpreted as relative to the original .css file,
> and converted so that they are still valid references to the
> desired file.
> - Other URLs (e.g., URLs with server names) are left alone.
>
> So, if the context path is MyApp, and the skin is
> at MyApp/skins/mySkin/skin.css
>
> url('http://foo/my.gif') -> http://foo/my.gif
> url('/my.gif') -> /MyApp/my.gif
> url('//images/my.gif') -> /images/my.gif
> url('images/my.gif') -> /MyApp/skins/mySkin/images/my.gif
> url('../../images/my.gif') -> /MyApp/images/my.gif
>
> -- Adam
>
>
>
> On 8/14/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
>
>> Hello all,
>>
>> I provided a patch for ADFFACES-121. However, I'm not totally satisfied
>> with it.
>>
>> Before the patch, the code was only converting the urls of
>> background-image property when placed inside url( ). My patch
>> converts all
>> values inside url( ) as well as background-image property value when not
>> placed inside url( ). For instance:
>>
>> Skin:
>>
>> background: url('images/myGif.gif');
>> background: images/myGif.gif;
>> background-image: url('images/myGif.gif');
>> background-image: images/myGif.gif;
>>
>>
>> Result with "MyApp" context root:
>>
>> background: url('/MyApp/skins/mySkin/images/myGif.gif');
>> background: images/myGif.gif;
>> background-image: url('/MyApp/skins/mySkin/images/myGif.gif');
>> background-image: /MyApp/skins/mySkin/images/myGif.gif;
>>
>>
>> It's a kind of inconsistency that could mix the user I think. I
>> therefore
>> see two possibilities:
>> 1. Convert only but all values specified inside url( ), leaving others
>> unchanged.
>> 2. Make sure the hard coded list of property names allowing property
>> values is exhaustive and document it accordingly.
>>
>>
>> Which one would be better? My vote goes to 1. since it will be easier to
>> document and maintain.
>>
>>
>> Regards,
>>
>> Simon Lessard
>> Fujitsu Consulting
>>
>
Re: [Proposal] Skin: Convert url values to context relative path only when
enclosed in url( )
Posted by Si...@DMR.CA.
+1 for option #3. I also like the 4 rules, so +1 for those as well.
Simon Lessard
Fujitsu Consulting
"Adam Winer" <aw...@gmail.com>
2006-08-14 12:01
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject: Re: [Proposal] Skin: Convert url values to context
relative path only when enclosed in url( )
The spec - http://www.w3.org/TR/CSS21/syndata.html#value-def-uri -
seems clear that url() is required (though quotes are not required).
I'd favor an option #3:
- Convert url(); anything other than than this syntax gets dropped
and logged with a warning
But we should talk about the manner of URL conversion here; IMO,
the rules should be:
- URLs beginning with a slash get prefixed with the context root
(like other such URLs in JSF)
- URLs beginning with two slashes get trimmed to a single slash
(special Trinidad URL rule, already used in Trinidad components)
- Relative URLs get interpreted as relative to the original .css file,
and converted so that they are still valid references to the
desired file.
- Other URLs (e.g., URLs with server names) are left alone.
So, if the context path is MyApp, and the skin is
at MyApp/skins/mySkin/skin.css
url('http://foo/my.gif') -> http://foo/my.gif
url('/my.gif') -> /MyApp/my.gif
url('//images/my.gif') -> /images/my.gif
url('images/my.gif') -> /MyApp/skins/mySkin/images/my.gif
url('../../images/my.gif') -> /MyApp/images/my.gif
-- Adam
On 8/14/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> Hello all,
>
> I provided a patch for ADFFACES-121. However, I'm not totally satisfied
> with it.
>
> Before the patch, the code was only converting the urls of
> background-image property when placed inside url( ). My patch converts
all
> values inside url( ) as well as background-image property value when not
> placed inside url( ). For instance:
>
> Skin:
>
> background: url('images/myGif.gif');
> background: images/myGif.gif;
> background-image: url('images/myGif.gif');
> background-image: images/myGif.gif;
>
>
> Result with "MyApp" context root:
>
> background: url('/MyApp/skins/mySkin/images/myGif.gif');
> background: images/myGif.gif;
> background-image: url('/MyApp/skins/mySkin/images/myGif.gif');
> background-image: /MyApp/skins/mySkin/images/myGif.gif;
>
>
> It's a kind of inconsistency that could mix the user I think. I
therefore
> see two possibilities:
> 1. Convert only but all values specified inside url( ), leaving others
> unchanged.
> 2. Make sure the hard coded list of property names allowing property
> values is exhaustive and document it accordingly.
>
>
> Which one would be better? My vote goes to 1. since it will be easier to
> document and maintain.
>
>
> Regards,
>
> Simon Lessard
> Fujitsu Consulting
>
Re: [Proposal] Skin: Convert url values to context relative path only when enclosed in url( )
Posted by Adam Winer <aw...@gmail.com>.
The spec - http://www.w3.org/TR/CSS21/syndata.html#value-def-uri -
seems clear that url() is required (though quotes are not required).
I'd favor an option #3:
- Convert url(); anything other than than this syntax gets dropped
and logged with a warning
But we should talk about the manner of URL conversion here; IMO,
the rules should be:
- URLs beginning with a slash get prefixed with the context root
(like other such URLs in JSF)
- URLs beginning with two slashes get trimmed to a single slash
(special Trinidad URL rule, already used in Trinidad components)
- Relative URLs get interpreted as relative to the original .css file,
and converted so that they are still valid references to the
desired file.
- Other URLs (e.g., URLs with server names) are left alone.
So, if the context path is MyApp, and the skin is
at MyApp/skins/mySkin/skin.css
url('http://foo/my.gif') -> http://foo/my.gif
url('/my.gif') -> /MyApp/my.gif
url('//images/my.gif') -> /images/my.gif
url('images/my.gif') -> /MyApp/skins/mySkin/images/my.gif
url('../../images/my.gif') -> /MyApp/images/my.gif
-- Adam
On 8/14/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
> Hello all,
>
> I provided a patch for ADFFACES-121. However, I'm not totally satisfied
> with it.
>
> Before the patch, the code was only converting the urls of
> background-image property when placed inside url( ). My patch converts all
> values inside url( ) as well as background-image property value when not
> placed inside url( ). For instance:
>
> Skin:
>
> background: url('images/myGif.gif');
> background: images/myGif.gif;
> background-image: url('images/myGif.gif');
> background-image: images/myGif.gif;
>
>
> Result with "MyApp" context root:
>
> background: url('/MyApp/skins/mySkin/images/myGif.gif');
> background: images/myGif.gif;
> background-image: url('/MyApp/skins/mySkin/images/myGif.gif');
> background-image: /MyApp/skins/mySkin/images/myGif.gif;
>
>
> It's a kind of inconsistency that could mix the user I think. I therefore
> see two possibilities:
> 1. Convert only but all values specified inside url( ), leaving others
> unchanged.
> 2. Make sure the hard coded list of property names allowing property
> values is exhaustive and document it accordingly.
>
>
> Which one would be better? My vote goes to 1. since it will be easier to
> document and maintain.
>
>
> Regards,
>
> Simon Lessard
> Fujitsu Consulting
>
[Proposal] Skin: Convert url values to context relative path only when
enclosed in url( )
Posted by Si...@DMR.CA.
Hello all,
I provided a patch for ADFFACES-121. However, I'm not totally satisfied
with it.
Before the patch, the code was only converting the urls of
background-image property when placed inside url( ). My patch converts all
values inside url( ) as well as background-image property value when not
placed inside url( ). For instance:
Skin:
background: url('images/myGif.gif');
background: images/myGif.gif;
background-image: url('images/myGif.gif');
background-image: images/myGif.gif;
Result with "MyApp" context root:
background: url('/MyApp/skins/mySkin/images/myGif.gif');
background: images/myGif.gif;
background-image: url('/MyApp/skins/mySkin/images/myGif.gif');
background-image: /MyApp/skins/mySkin/images/myGif.gif;
It's a kind of inconsistency that could mix the user I think. I therefore
see two possibilities:
1. Convert only but all values specified inside url( ), leaving others
unchanged.
2. Make sure the hard coded list of property names allowing property
values is exhaustive and document it accordingly.
Which one would be better? My vote goes to 1. since it will be easier to
document and maintain.
Regards,
Simon Lessard
Fujitsu Consulting