You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Luther Baker <lu...@gmail.com> on 2008/09/14 15:42:57 UTC
ordering of stylesheets
I have a small question. I have a component (htmlWrapper) that encapsulates
each of my pages. I guess you'd call it a custom layout component. Each of
my pages generally do something like
<t:htmlWrapper ...>
body here
</t:htmlWrapper>
This layout component includes basic or common css stylesheets. *My problem
is this: I want each individual page to be able to add and override styles
based on this common stylesheet.* Unfortunately, I don't see a definitive
way to ORDER the stylesheets in the render process. At least, not
declaratively or from the leaf nodes (*.tml or Java files associated with
page or component).
For instance, my personal thoughts were that stylesheets in the *.tml files
should come first.
a) individual pages generally want to OVERRIDE the more generic template
styles sheets. page style sheets should come last.
b) if you use a layout component (which I have to guess most everyone does),
the pages them selves don't even have a <head> section and so would
generally not include stylesheets in the *.tml file. My actually pages
generally use the stylesheet annotation in the java files. Include those
last.
So that was my blatantly simple thought. It may not work in every case but
it would create some sense of order. Stylsheets in TML files always preceed
stylesheets defined in Java files. I guess this could be simplified to
"stylesheets from Java files should always be LAST in the <head> section.
If that is hard to do ... another thought would be to have a custom
component rendered in the <head> section that would be substituted with Java
stylesheets includes. Then I could literally put it wherever I wanted.
Unfortunately, this comes back to my earlier post - that the <head> section
really gets rewritten in a subtley non-satisafactory way. If using XHTML
DOCTYPE, when generating the <head> tag,
It'd be nice if, out of the box, Tapestry would:
a) include include ContentType meta tag first, the language and content type
should/must preceed all other content in the file
b) include all javascript files in the head, I believe it is invalid per the
XHTML DTD to place <script> tags in the <body> but if not, conventionally,
<script> tags are supposed to reside only in <head>
c) predictably order the stylessheets so that page specific css files can
predicably override common or shared css files.
Obviously, just my $0.02.
So back to my early question about ordering stylesheets ... is that easy to
do? Good suggestion? Bad suggestion?
Thanks,
-Luther
Re: ordering of stylesheets
Posted by Luther Baker <lu...@gmail.com>.
That led me to the workaround as well.
Thanks for this pointer.
-Luther
On Mon, Sep 15, 2008 at 3:36 AM, Hugo Palma <hu...@gmail.com> wrote:
> There's an issue regarding the stylesheet ordering (
> https://issues.apache.org/jira/browse/TAPESTRY-2356)
>
>
> Luther Baker wrote:
>
>> Wonderful. Thanks for the extended response.
>>
>> Ah ... you are right! Per your comment regarding (c) I took a look at
>> http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd and found valid paths
>> to
>> script in both the head and body ...
>>
>> Thanks again.
>>
>> -Luther
>>
>>
>>
>>
>> On Sun, Sep 14, 2008 at 2:49 PM, Filip S. Adamsen <fs...@fsadev.com> wrote:
>>
>>
>>
>>> Hi,
>>>
>>> On 2008-09-14 18:01, Luther Baker wrote:
>>>
>>>
>>>
>>>> Thanks Filip.
>>>>
>>>> I've actually implemented the XHTML reference you pointed to and it did
>>>> help
>>>> with things like closing the link and meta tags. I am still hoping that
>>>> this
>>>> gets fixed so that it works out of the box though. The library is so
>>>> rigorous at parsing my input, valid XHTML output should be part of the
>>>> standard download. I'd suggest that for Tapestry to significantly
>>>> increase
>>>> its adoption rate, issues like these should probably work out of the
>>>> box.
>>>>
>>>>
>>>>
>>> It's tricky. Not everyone wants to use XHTML 1.0 - and especially not
>>> XHTML
>>> 1.0 Strict. But I agree it should be easier to do. Certainly, having the
>>> classes from the wiki included in the distribution would help, along with
>>> relevant documentation.
>>>
>>> One of the things that really suck about XHTML 1.0 is that <form/> allows
>>> a
>>> name attribute in 1.0 Transitional, but not in 1.0 Strict. I've had to
>>> make
>>> my own Form component to get around that, because Tapestry emits the name
>>> attribute by default. (Actually, I need my own form component anyway, but
>>> that's beside the point.)
>>>
>>> What that handy link didn't really address was the ability to (a) order
>>>
>>>
>>>> the
>>>> stylesheets (b) add closing </option> tags to the beaneditform or (c)
>>>> put
>>>> the javascript files in the header. Again this is generally all form
>>>> over
>>>> function ... except that the ordering of stylesheets is a well practiced
>>>> idiom that many sites predictably depend on ... but nevertheless, no big
>>>> deal.
>>>>
>>>>
>>>>
>>> a) I totally agree on the ordering of stylesheets. Actually, the whole
>>> stylesheets mechanism, while good, isn't quite there. An easier way to
>>> order
>>> stylesheets - like, having page stylesheets override component
>>> stylesheets
>>> or some such - is needed.
>>>
>>> b) I don't use BeanEditForm, but I use Select - and option elements are
>>> closed as they should be... weird.
>>>
>>> c) Tapestry does the right thing here. Unfortunately, this doesn't work
>>> well - if at all - with old or badly written scripts.
>>>
>>> Thanks for the point on @IncludeStylesheet annotation. I didn't follow
>>>
>>>
>>>> your
>>>> statement exactly. You mention an alternative but its not clear what
>>>> that
>>>> is. I'm just not sure how to use this suggestion
>>>> RenderSupport#addStyleSheetLink. Is that a class#method that need to
>>>> invoke
>>>> directly? Is it a static method? Is it an annotation? ... I see javadoc
>>>> and
>>>> it looks like an interface - but not sure what to do with it. I'll try
>>>> to
>>>> find it on the tapestry5 site.
>>>>
>>>>
>>>>
>>> RenderSupport is an environmental service:
>>> http://tapestry.apache.org/tapestry5/guide/env.html
>>>
>>> You use it like this:
>>>
>>> @Environmental
>>> private RenderSupport renderSupport;
>>>
>>> void afterRender() {
>>> renderSupport.addStylesheetLink(...);
>>> }
>>>
>>> Thanks for the response.
>>> You're welcome.
>>>
>>> -Luther
>>> -Filip
>>>
>>>
>>> On Sun, Sep 14, 2008 at 10:39 AM, Filip S. Adamsen <fs...@fsadev.com>
>>>
>>>
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>>
>>>>> Using an XHTML DTD isn't enough to make Tapestry output correct XHTML.
>>>>>
>>>>> See http://wiki.apache.org/tapestry/Tapestry5HowToXhtml for more about
>>>>> that. It needs to be updated, though, something I might do later today
>>>>> if
>>>>> I
>>>>> get time.
>>>>>
>>>>> Wrt. @IncludeStylesheet, there's an alternative that lets you specify
>>>>> the
>>>>> media type of the stylesheet - use RenderSupport#addStylesheetLink.
>>>>>
>>>>> -Filip
>>>>>
>>>>>
>>>>> On 2008-09-14 15:46, Luther Baker wrote:
>>>>>
>>>>> Oh yes ... and out of the box ... it'd be nice if Tapestry properly
>>>>>
>>>>>
>>>>>> closed
>>>>>> <link> and <meta> tags.
>>>>>>
>>>>>> (There are several more attributes to a link tag ... are those
>>>>>> possible
>>>>>> @IncludeStylesheet annotation parameters?)
>>>>>>
>>>>>> Hey ... just suggestions if anyone's taking notes.
>>>>>>
>>>>>> Generally love the concept and current implementation.
>>>>>>
>>>>>> -Luther
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Sep 14, 2008 at 8:42 AM, Luther Baker <lu...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> I have a small question. I have a component (htmlWrapper) that
>>>>>>
>>>>>>
>>>>>>
>>>>>>> encapsulates
>>>>>>> each of my pages. I guess you'd call it a custom layout component.
>>>>>>> Each
>>>>>>> of
>>>>>>> my pages generally do something like
>>>>>>>
>>>>>>> <t:htmlWrapper ...>
>>>>>>> body here
>>>>>>> </t:htmlWrapper>
>>>>>>>
>>>>>>> This layout component includes basic or common css stylesheets. *My
>>>>>>> problem is this: I want each individual page to be able to add and
>>>>>>> override
>>>>>>> styles based on this common stylesheet.* Unfortunately, I don't see a
>>>>>>> definitive way to ORDER the stylesheets in the render process. At
>>>>>>> least,
>>>>>>> not
>>>>>>> declaratively or from the leaf nodes (*.tml or Java files associated
>>>>>>> with
>>>>>>> page or component).
>>>>>>>
>>>>>>> For instance, my personal thoughts were that stylesheets in the *.tml
>>>>>>> files
>>>>>>> should come first.
>>>>>>>
>>>>>>> a) individual pages generally want to OVERRIDE the more generic
>>>>>>> template
>>>>>>> styles sheets. page style sheets should come last.
>>>>>>> b) if you use a layout component (which I have to guess most everyone
>>>>>>> does), the pages them selves don't even have a <head> section and so
>>>>>>> would
>>>>>>> generally not include stylesheets in the *.tml file. My actually
>>>>>>> pages
>>>>>>> generally use the stylesheet annotation in the java files. Include
>>>>>>> those
>>>>>>> last.
>>>>>>>
>>>>>>> So that was my blatantly simple thought. It may not work in every
>>>>>>> case
>>>>>>> but
>>>>>>> it would create some sense of order. Stylsheets in TML files always
>>>>>>> preceed
>>>>>>> stylesheets defined in Java files. I guess this could be simplified
>>>>>>> to
>>>>>>> "stylesheets from Java files should always be LAST in the <head>
>>>>>>> section.
>>>>>>>
>>>>>>> If that is hard to do ... another thought would be to have a custom
>>>>>>> component rendered in the <head> section that would be substituted
>>>>>>> with
>>>>>>> Java
>>>>>>> stylesheets includes. Then I could literally put it wherever I
>>>>>>> wanted.
>>>>>>> Unfortunately, this comes back to my earlier post - that the <head>
>>>>>>> section
>>>>>>> really gets rewritten in a subtley non-satisafactory way. If using
>>>>>>> XHTML
>>>>>>> DOCTYPE, when generating the <head> tag,
>>>>>>>
>>>>>>> It'd be nice if, out of the box, Tapestry would:
>>>>>>>
>>>>>>> a) include include ContentType meta tag first, the language and
>>>>>>> content
>>>>>>> type should/must preceed all other content in the file
>>>>>>> b) include all javascript files in the head, I believe it is invalid
>>>>>>> per
>>>>>>> the XHTML DTD to place <script> tags in the <body> but if not,
>>>>>>> conventionally, <script> tags are supposed to reside only in <head>
>>>>>>> c) predictably order the stylessheets so that page specific css files
>>>>>>> can
>>>>>>> predicably override common or shared css files.
>>>>>>>
>>>>>>> Obviously, just my $0.02.
>>>>>>>
>>>>>>> So back to my early question about ordering stylesheets ... is that
>>>>>>> easy
>>>>>>> to
>>>>>>> do? Good suggestion? Bad suggestion?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -Luther
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>>>
>>
>>
>>
>
Re: ordering of stylesheets
Posted by Hugo Palma <hu...@gmail.com>.
There's an issue regarding the stylesheet ordering
(https://issues.apache.org/jira/browse/TAPESTRY-2356)
Luther Baker wrote:
> Wonderful. Thanks for the extended response.
>
> Ah ... you are right! Per your comment regarding (c) I took a look at
> http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd and found valid paths to
> script in both the head and body ...
>
> Thanks again.
>
> -Luther
>
>
>
>
> On Sun, Sep 14, 2008 at 2:49 PM, Filip S. Adamsen <fs...@fsadev.com> wrote:
>
>
>> Hi,
>>
>> On 2008-09-14 18:01, Luther Baker wrote:
>>
>>
>>> Thanks Filip.
>>>
>>> I've actually implemented the XHTML reference you pointed to and it did
>>> help
>>> with things like closing the link and meta tags. I am still hoping that
>>> this
>>> gets fixed so that it works out of the box though. The library is so
>>> rigorous at parsing my input, valid XHTML output should be part of the
>>> standard download. I'd suggest that for Tapestry to significantly increase
>>> its adoption rate, issues like these should probably work out of the box.
>>>
>>>
>> It's tricky. Not everyone wants to use XHTML 1.0 - and especially not XHTML
>> 1.0 Strict. But I agree it should be easier to do. Certainly, having the
>> classes from the wiki included in the distribution would help, along with
>> relevant documentation.
>>
>> One of the things that really suck about XHTML 1.0 is that <form/> allows a
>> name attribute in 1.0 Transitional, but not in 1.0 Strict. I've had to make
>> my own Form component to get around that, because Tapestry emits the name
>> attribute by default. (Actually, I need my own form component anyway, but
>> that's beside the point.)
>>
>> What that handy link didn't really address was the ability to (a) order
>>
>>> the
>>> stylesheets (b) add closing </option> tags to the beaneditform or (c) put
>>> the javascript files in the header. Again this is generally all form over
>>> function ... except that the ordering of stylesheets is a well practiced
>>> idiom that many sites predictably depend on ... but nevertheless, no big
>>> deal.
>>>
>>>
>> a) I totally agree on the ordering of stylesheets. Actually, the whole
>> stylesheets mechanism, while good, isn't quite there. An easier way to order
>> stylesheets - like, having page stylesheets override component stylesheets
>> or some such - is needed.
>>
>> b) I don't use BeanEditForm, but I use Select - and option elements are
>> closed as they should be... weird.
>>
>> c) Tapestry does the right thing here. Unfortunately, this doesn't work
>> well - if at all - with old or badly written scripts.
>>
>> Thanks for the point on @IncludeStylesheet annotation. I didn't follow
>>
>>> your
>>> statement exactly. You mention an alternative but its not clear what that
>>> is. I'm just not sure how to use this suggestion
>>> RenderSupport#addStyleSheetLink. Is that a class#method that need to
>>> invoke
>>> directly? Is it a static method? Is it an annotation? ... I see javadoc
>>> and
>>> it looks like an interface - but not sure what to do with it. I'll try to
>>> find it on the tapestry5 site.
>>>
>>>
>> RenderSupport is an environmental service:
>> http://tapestry.apache.org/tapestry5/guide/env.html
>>
>> You use it like this:
>>
>> @Environmental
>> private RenderSupport renderSupport;
>>
>> void afterRender() {
>> renderSupport.addStylesheetLink(...);
>> }
>>
>> Thanks for the response.
>>
>> You're welcome.
>>
>> -Luther
>>
>> -Filip
>>
>>
>> On Sun, Sep 14, 2008 at 10:39 AM, Filip S. Adamsen <fs...@fsadev.com>
>>
>>> wrote:
>>>
>>> Hi,
>>>
>>>> Using an XHTML DTD isn't enough to make Tapestry output correct XHTML.
>>>>
>>>> See http://wiki.apache.org/tapestry/Tapestry5HowToXhtml for more about
>>>> that. It needs to be updated, though, something I might do later today if
>>>> I
>>>> get time.
>>>>
>>>> Wrt. @IncludeStylesheet, there's an alternative that lets you specify the
>>>> media type of the stylesheet - use RenderSupport#addStylesheetLink.
>>>>
>>>> -Filip
>>>>
>>>>
>>>> On 2008-09-14 15:46, Luther Baker wrote:
>>>>
>>>> Oh yes ... and out of the box ... it'd be nice if Tapestry properly
>>>>
>>>>> closed
>>>>> <link> and <meta> tags.
>>>>>
>>>>> (There are several more attributes to a link tag ... are those
>>>>> possible
>>>>> @IncludeStylesheet annotation parameters?)
>>>>>
>>>>> Hey ... just suggestions if anyone's taking notes.
>>>>>
>>>>> Generally love the concept and current implementation.
>>>>>
>>>>> -Luther
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Sep 14, 2008 at 8:42 AM, Luther Baker <lu...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> I have a small question. I have a component (htmlWrapper) that
>>>>>
>>>>>
>>>>>> encapsulates
>>>>>> each of my pages. I guess you'd call it a custom layout component. Each
>>>>>> of
>>>>>> my pages generally do something like
>>>>>>
>>>>>> <t:htmlWrapper ...>
>>>>>> body here
>>>>>> </t:htmlWrapper>
>>>>>>
>>>>>> This layout component includes basic or common css stylesheets. *My
>>>>>> problem is this: I want each individual page to be able to add and
>>>>>> override
>>>>>> styles based on this common stylesheet.* Unfortunately, I don't see a
>>>>>> definitive way to ORDER the stylesheets in the render process. At
>>>>>> least,
>>>>>> not
>>>>>> declaratively or from the leaf nodes (*.tml or Java files associated
>>>>>> with
>>>>>> page or component).
>>>>>>
>>>>>> For instance, my personal thoughts were that stylesheets in the *.tml
>>>>>> files
>>>>>> should come first.
>>>>>>
>>>>>> a) individual pages generally want to OVERRIDE the more generic
>>>>>> template
>>>>>> styles sheets. page style sheets should come last.
>>>>>> b) if you use a layout component (which I have to guess most everyone
>>>>>> does), the pages them selves don't even have a <head> section and so
>>>>>> would
>>>>>> generally not include stylesheets in the *.tml file. My actually pages
>>>>>> generally use the stylesheet annotation in the java files. Include
>>>>>> those
>>>>>> last.
>>>>>>
>>>>>> So that was my blatantly simple thought. It may not work in every case
>>>>>> but
>>>>>> it would create some sense of order. Stylsheets in TML files always
>>>>>> preceed
>>>>>> stylesheets defined in Java files. I guess this could be simplified to
>>>>>> "stylesheets from Java files should always be LAST in the <head>
>>>>>> section.
>>>>>>
>>>>>> If that is hard to do ... another thought would be to have a custom
>>>>>> component rendered in the <head> section that would be substituted with
>>>>>> Java
>>>>>> stylesheets includes. Then I could literally put it wherever I wanted.
>>>>>> Unfortunately, this comes back to my earlier post - that the <head>
>>>>>> section
>>>>>> really gets rewritten in a subtley non-satisafactory way. If using
>>>>>> XHTML
>>>>>> DOCTYPE, when generating the <head> tag,
>>>>>>
>>>>>> It'd be nice if, out of the box, Tapestry would:
>>>>>>
>>>>>> a) include include ContentType meta tag first, the language and content
>>>>>> type should/must preceed all other content in the file
>>>>>> b) include all javascript files in the head, I believe it is invalid
>>>>>> per
>>>>>> the XHTML DTD to place <script> tags in the <body> but if not,
>>>>>> conventionally, <script> tags are supposed to reside only in <head>
>>>>>> c) predictably order the stylessheets so that page specific css files
>>>>>> can
>>>>>> predicably override common or shared css files.
>>>>>>
>>>>>> Obviously, just my $0.02.
>>>>>>
>>>>>> So back to my early question about ordering stylesheets ... is that
>>>>>> easy
>>>>>> to
>>>>>> do? Good suggestion? Bad suggestion?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -Luther
>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
>
Re: ordering of stylesheets
Posted by Luther Baker <lu...@gmail.com>.
Wonderful. Thanks for the extended response.
Ah ... you are right! Per your comment regarding (c) I took a look at
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd and found valid paths to
script in both the head and body ...
Thanks again.
-Luther
On Sun, Sep 14, 2008 at 2:49 PM, Filip S. Adamsen <fs...@fsadev.com> wrote:
> Hi,
>
> On 2008-09-14 18:01, Luther Baker wrote:
>
>> Thanks Filip.
>>
>> I've actually implemented the XHTML reference you pointed to and it did
>> help
>> with things like closing the link and meta tags. I am still hoping that
>> this
>> gets fixed so that it works out of the box though. The library is so
>> rigorous at parsing my input, valid XHTML output should be part of the
>> standard download. I'd suggest that for Tapestry to significantly increase
>> its adoption rate, issues like these should probably work out of the box.
>>
>
> It's tricky. Not everyone wants to use XHTML 1.0 - and especially not XHTML
> 1.0 Strict. But I agree it should be easier to do. Certainly, having the
> classes from the wiki included in the distribution would help, along with
> relevant documentation.
>
> One of the things that really suck about XHTML 1.0 is that <form/> allows a
> name attribute in 1.0 Transitional, but not in 1.0 Strict. I've had to make
> my own Form component to get around that, because Tapestry emits the name
> attribute by default. (Actually, I need my own form component anyway, but
> that's beside the point.)
>
> What that handy link didn't really address was the ability to (a) order
>> the
>> stylesheets (b) add closing </option> tags to the beaneditform or (c) put
>> the javascript files in the header. Again this is generally all form over
>> function ... except that the ordering of stylesheets is a well practiced
>> idiom that many sites predictably depend on ... but nevertheless, no big
>> deal.
>>
>
> a) I totally agree on the ordering of stylesheets. Actually, the whole
> stylesheets mechanism, while good, isn't quite there. An easier way to order
> stylesheets - like, having page stylesheets override component stylesheets
> or some such - is needed.
>
> b) I don't use BeanEditForm, but I use Select - and option elements are
> closed as they should be... weird.
>
> c) Tapestry does the right thing here. Unfortunately, this doesn't work
> well - if at all - with old or badly written scripts.
>
> Thanks for the point on @IncludeStylesheet annotation. I didn't follow
>> your
>> statement exactly. You mention an alternative but its not clear what that
>> is. I'm just not sure how to use this suggestion
>> RenderSupport#addStyleSheetLink. Is that a class#method that need to
>> invoke
>> directly? Is it a static method? Is it an annotation? ... I see javadoc
>> and
>> it looks like an interface - but not sure what to do with it. I'll try to
>> find it on the tapestry5 site.
>>
>
> RenderSupport is an environmental service:
> http://tapestry.apache.org/tapestry5/guide/env.html
>
> You use it like this:
>
> @Environmental
> private RenderSupport renderSupport;
>
> void afterRender() {
> renderSupport.addStylesheetLink(...);
> }
>
> Thanks for the response.
>>
>
> You're welcome.
>
> -Luther
>>
>
> -Filip
>
>
> On Sun, Sep 14, 2008 at 10:39 AM, Filip S. Adamsen <fs...@fsadev.com>
>> wrote:
>>
>> Hi,
>>>
>>> Using an XHTML DTD isn't enough to make Tapestry output correct XHTML.
>>>
>>> See http://wiki.apache.org/tapestry/Tapestry5HowToXhtml for more about
>>> that. It needs to be updated, though, something I might do later today if
>>> I
>>> get time.
>>>
>>> Wrt. @IncludeStylesheet, there's an alternative that lets you specify the
>>> media type of the stylesheet - use RenderSupport#addStylesheetLink.
>>>
>>> -Filip
>>>
>>>
>>> On 2008-09-14 15:46, Luther Baker wrote:
>>>
>>> Oh yes ... and out of the box ... it'd be nice if Tapestry properly
>>>> closed
>>>> <link> and <meta> tags.
>>>>
>>>> (There are several more attributes to a link tag ... are those
>>>> possible
>>>> @IncludeStylesheet annotation parameters?)
>>>>
>>>> Hey ... just suggestions if anyone's taking notes.
>>>>
>>>> Generally love the concept and current implementation.
>>>>
>>>> -Luther
>>>>
>>>>
>>>>
>>>> On Sun, Sep 14, 2008 at 8:42 AM, Luther Baker <lu...@gmail.com>
>>>> wrote:
>>>>
>>>> I have a small question. I have a component (htmlWrapper) that
>>>>
>>>>> encapsulates
>>>>> each of my pages. I guess you'd call it a custom layout component. Each
>>>>> of
>>>>> my pages generally do something like
>>>>>
>>>>> <t:htmlWrapper ...>
>>>>> body here
>>>>> </t:htmlWrapper>
>>>>>
>>>>> This layout component includes basic or common css stylesheets. *My
>>>>> problem is this: I want each individual page to be able to add and
>>>>> override
>>>>> styles based on this common stylesheet.* Unfortunately, I don't see a
>>>>> definitive way to ORDER the stylesheets in the render process. At
>>>>> least,
>>>>> not
>>>>> declaratively or from the leaf nodes (*.tml or Java files associated
>>>>> with
>>>>> page or component).
>>>>>
>>>>> For instance, my personal thoughts were that stylesheets in the *.tml
>>>>> files
>>>>> should come first.
>>>>>
>>>>> a) individual pages generally want to OVERRIDE the more generic
>>>>> template
>>>>> styles sheets. page style sheets should come last.
>>>>> b) if you use a layout component (which I have to guess most everyone
>>>>> does), the pages them selves don't even have a <head> section and so
>>>>> would
>>>>> generally not include stylesheets in the *.tml file. My actually pages
>>>>> generally use the stylesheet annotation in the java files. Include
>>>>> those
>>>>> last.
>>>>>
>>>>> So that was my blatantly simple thought. It may not work in every case
>>>>> but
>>>>> it would create some sense of order. Stylsheets in TML files always
>>>>> preceed
>>>>> stylesheets defined in Java files. I guess this could be simplified to
>>>>> "stylesheets from Java files should always be LAST in the <head>
>>>>> section.
>>>>>
>>>>> If that is hard to do ... another thought would be to have a custom
>>>>> component rendered in the <head> section that would be substituted with
>>>>> Java
>>>>> stylesheets includes. Then I could literally put it wherever I wanted.
>>>>> Unfortunately, this comes back to my earlier post - that the <head>
>>>>> section
>>>>> really gets rewritten in a subtley non-satisafactory way. If using
>>>>> XHTML
>>>>> DOCTYPE, when generating the <head> tag,
>>>>>
>>>>> It'd be nice if, out of the box, Tapestry would:
>>>>>
>>>>> a) include include ContentType meta tag first, the language and content
>>>>> type should/must preceed all other content in the file
>>>>> b) include all javascript files in the head, I believe it is invalid
>>>>> per
>>>>> the XHTML DTD to place <script> tags in the <body> but if not,
>>>>> conventionally, <script> tags are supposed to reside only in <head>
>>>>> c) predictably order the stylessheets so that page specific css files
>>>>> can
>>>>> predicably override common or shared css files.
>>>>>
>>>>> Obviously, just my $0.02.
>>>>>
>>>>> So back to my early question about ordering stylesheets ... is that
>>>>> easy
>>>>> to
>>>>> do? Good suggestion? Bad suggestion?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Luther
>>>>>
>>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: ordering of stylesheets
Posted by "Filip S. Adamsen" <fs...@fsadev.com>.
Hi,
On 2008-09-14 18:01, Luther Baker wrote:
> Thanks Filip.
>
> I've actually implemented the XHTML reference you pointed to and it did help
> with things like closing the link and meta tags. I am still hoping that this
> gets fixed so that it works out of the box though. The library is so
> rigorous at parsing my input, valid XHTML output should be part of the
> standard download. I'd suggest that for Tapestry to significantly increase
> its adoption rate, issues like these should probably work out of the box.
It's tricky. Not everyone wants to use XHTML 1.0 - and especially not
XHTML 1.0 Strict. But I agree it should be easier to do. Certainly,
having the classes from the wiki included in the distribution would
help, along with relevant documentation.
One of the things that really suck about XHTML 1.0 is that <form/>
allows a name attribute in 1.0 Transitional, but not in 1.0 Strict. I've
had to make my own Form component to get around that, because Tapestry
emits the name attribute by default. (Actually, I need my own form
component anyway, but that's beside the point.)
> What that handy link didn't really address was the ability to (a) order the
> stylesheets (b) add closing </option> tags to the beaneditform or (c) put
> the javascript files in the header. Again this is generally all form over
> function ... except that the ordering of stylesheets is a well practiced
> idiom that many sites predictably depend on ... but nevertheless, no big
> deal.
a) I totally agree on the ordering of stylesheets. Actually, the whole
stylesheets mechanism, while good, isn't quite there. An easier way to
order stylesheets - like, having page stylesheets override component
stylesheets or some such - is needed.
b) I don't use BeanEditForm, but I use Select - and option elements are
closed as they should be... weird.
c) Tapestry does the right thing here. Unfortunately, this doesn't work
well - if at all - with old or badly written scripts.
> Thanks for the point on @IncludeStylesheet annotation. I didn't follow your
> statement exactly. You mention an alternative but its not clear what that
> is. I'm just not sure how to use this suggestion
> RenderSupport#addStyleSheetLink. Is that a class#method that need to invoke
> directly? Is it a static method? Is it an annotation? ... I see javadoc and
> it looks like an interface - but not sure what to do with it. I'll try to
> find it on the tapestry5 site.
RenderSupport is an environmental service:
http://tapestry.apache.org/tapestry5/guide/env.html
You use it like this:
@Environmental
private RenderSupport renderSupport;
void afterRender() {
renderSupport.addStylesheetLink(...);
}
> Thanks for the response.
You're welcome.
> -Luther
-Filip
> On Sun, Sep 14, 2008 at 10:39 AM, Filip S. Adamsen <fs...@fsadev.com> wrote:
>
>> Hi,
>>
>> Using an XHTML DTD isn't enough to make Tapestry output correct XHTML.
>>
>> See http://wiki.apache.org/tapestry/Tapestry5HowToXhtml for more about
>> that. It needs to be updated, though, something I might do later today if I
>> get time.
>>
>> Wrt. @IncludeStylesheet, there's an alternative that lets you specify the
>> media type of the stylesheet - use RenderSupport#addStylesheetLink.
>>
>> -Filip
>>
>>
>> On 2008-09-14 15:46, Luther Baker wrote:
>>
>>> Oh yes ... and out of the box ... it'd be nice if Tapestry properly closed
>>> <link> and <meta> tags.
>>>
>>> (There are several more attributes to a link tag ... are those possible
>>> @IncludeStylesheet annotation parameters?)
>>>
>>> Hey ... just suggestions if anyone's taking notes.
>>>
>>> Generally love the concept and current implementation.
>>>
>>> -Luther
>>>
>>>
>>>
>>> On Sun, Sep 14, 2008 at 8:42 AM, Luther Baker <lu...@gmail.com>
>>> wrote:
>>>
>>> I have a small question. I have a component (htmlWrapper) that
>>>> encapsulates
>>>> each of my pages. I guess you'd call it a custom layout component. Each
>>>> of
>>>> my pages generally do something like
>>>>
>>>> <t:htmlWrapper ...>
>>>> body here
>>>> </t:htmlWrapper>
>>>>
>>>> This layout component includes basic or common css stylesheets. *My
>>>> problem is this: I want each individual page to be able to add and
>>>> override
>>>> styles based on this common stylesheet.* Unfortunately, I don't see a
>>>> definitive way to ORDER the stylesheets in the render process. At least,
>>>> not
>>>> declaratively or from the leaf nodes (*.tml or Java files associated with
>>>> page or component).
>>>>
>>>> For instance, my personal thoughts were that stylesheets in the *.tml
>>>> files
>>>> should come first.
>>>>
>>>> a) individual pages generally want to OVERRIDE the more generic template
>>>> styles sheets. page style sheets should come last.
>>>> b) if you use a layout component (which I have to guess most everyone
>>>> does), the pages them selves don't even have a <head> section and so
>>>> would
>>>> generally not include stylesheets in the *.tml file. My actually pages
>>>> generally use the stylesheet annotation in the java files. Include those
>>>> last.
>>>>
>>>> So that was my blatantly simple thought. It may not work in every case
>>>> but
>>>> it would create some sense of order. Stylsheets in TML files always
>>>> preceed
>>>> stylesheets defined in Java files. I guess this could be simplified to
>>>> "stylesheets from Java files should always be LAST in the <head> section.
>>>>
>>>> If that is hard to do ... another thought would be to have a custom
>>>> component rendered in the <head> section that would be substituted with
>>>> Java
>>>> stylesheets includes. Then I could literally put it wherever I wanted.
>>>> Unfortunately, this comes back to my earlier post - that the <head>
>>>> section
>>>> really gets rewritten in a subtley non-satisafactory way. If using XHTML
>>>> DOCTYPE, when generating the <head> tag,
>>>>
>>>> It'd be nice if, out of the box, Tapestry would:
>>>>
>>>> a) include include ContentType meta tag first, the language and content
>>>> type should/must preceed all other content in the file
>>>> b) include all javascript files in the head, I believe it is invalid per
>>>> the XHTML DTD to place <script> tags in the <body> but if not,
>>>> conventionally, <script> tags are supposed to reside only in <head>
>>>> c) predictably order the stylessheets so that page specific css files can
>>>> predicably override common or shared css files.
>>>>
>>>> Obviously, just my $0.02.
>>>>
>>>> So back to my early question about ordering stylesheets ... is that easy
>>>> to
>>>> do? Good suggestion? Bad suggestion?
>>>>
>>>> Thanks,
>>>>
>>>> -Luther
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: ordering of stylesheets
Posted by Luther Baker <lu...@gmail.com>.
Thanks Filip.
I've actually implemented the XHTML reference you pointed to and it did help
with things like closing the link and meta tags. I am still hoping that this
gets fixed so that it works out of the box though. The library is so
rigorous at parsing my input, valid XHTML output should be part of the
standard download. I'd suggest that for Tapestry to significantly increase
its adoption rate, issues like these should probably work out of the box.
What that handy link didn't really address was the ability to (a) order the
stylesheets (b) add closing </option> tags to the beaneditform or (c) put
the javascript files in the header. Again this is generally all form over
function ... except that the ordering of stylesheets is a well practiced
idiom that many sites predictably depend on ... but nevertheless, no big
deal.
Thanks for the point on @IncludeStylesheet annotation. I didn't follow your
statement exactly. You mention an alternative but its not clear what that
is. I'm just not sure how to use this suggestion
RenderSupport#addStyleSheetLink. Is that a class#method that need to invoke
directly? Is it a static method? Is it an annotation? ... I see javadoc and
it looks like an interface - but not sure what to do with it. I'll try to
find it on the tapestry5 site.
Thanks for the response.
-Luther
On Sun, Sep 14, 2008 at 10:39 AM, Filip S. Adamsen <fs...@fsadev.com> wrote:
> Hi,
>
> Using an XHTML DTD isn't enough to make Tapestry output correct XHTML.
>
> See http://wiki.apache.org/tapestry/Tapestry5HowToXhtml for more about
> that. It needs to be updated, though, something I might do later today if I
> get time.
>
> Wrt. @IncludeStylesheet, there's an alternative that lets you specify the
> media type of the stylesheet - use RenderSupport#addStylesheetLink.
>
> -Filip
>
>
> On 2008-09-14 15:46, Luther Baker wrote:
>
>> Oh yes ... and out of the box ... it'd be nice if Tapestry properly closed
>> <link> and <meta> tags.
>>
>> (There are several more attributes to a link tag ... are those possible
>> @IncludeStylesheet annotation parameters?)
>>
>> Hey ... just suggestions if anyone's taking notes.
>>
>> Generally love the concept and current implementation.
>>
>> -Luther
>>
>>
>>
>> On Sun, Sep 14, 2008 at 8:42 AM, Luther Baker <lu...@gmail.com>
>> wrote:
>>
>> I have a small question. I have a component (htmlWrapper) that
>>> encapsulates
>>> each of my pages. I guess you'd call it a custom layout component. Each
>>> of
>>> my pages generally do something like
>>>
>>> <t:htmlWrapper ...>
>>> body here
>>> </t:htmlWrapper>
>>>
>>> This layout component includes basic or common css stylesheets. *My
>>> problem is this: I want each individual page to be able to add and
>>> override
>>> styles based on this common stylesheet.* Unfortunately, I don't see a
>>> definitive way to ORDER the stylesheets in the render process. At least,
>>> not
>>> declaratively or from the leaf nodes (*.tml or Java files associated with
>>> page or component).
>>>
>>> For instance, my personal thoughts were that stylesheets in the *.tml
>>> files
>>> should come first.
>>>
>>> a) individual pages generally want to OVERRIDE the more generic template
>>> styles sheets. page style sheets should come last.
>>> b) if you use a layout component (which I have to guess most everyone
>>> does), the pages them selves don't even have a <head> section and so
>>> would
>>> generally not include stylesheets in the *.tml file. My actually pages
>>> generally use the stylesheet annotation in the java files. Include those
>>> last.
>>>
>>> So that was my blatantly simple thought. It may not work in every case
>>> but
>>> it would create some sense of order. Stylsheets in TML files always
>>> preceed
>>> stylesheets defined in Java files. I guess this could be simplified to
>>> "stylesheets from Java files should always be LAST in the <head> section.
>>>
>>> If that is hard to do ... another thought would be to have a custom
>>> component rendered in the <head> section that would be substituted with
>>> Java
>>> stylesheets includes. Then I could literally put it wherever I wanted.
>>> Unfortunately, this comes back to my earlier post - that the <head>
>>> section
>>> really gets rewritten in a subtley non-satisafactory way. If using XHTML
>>> DOCTYPE, when generating the <head> tag,
>>>
>>> It'd be nice if, out of the box, Tapestry would:
>>>
>>> a) include include ContentType meta tag first, the language and content
>>> type should/must preceed all other content in the file
>>> b) include all javascript files in the head, I believe it is invalid per
>>> the XHTML DTD to place <script> tags in the <body> but if not,
>>> conventionally, <script> tags are supposed to reside only in <head>
>>> c) predictably order the stylessheets so that page specific css files can
>>> predicably override common or shared css files.
>>>
>>> Obviously, just my $0.02.
>>>
>>> So back to my early question about ordering stylesheets ... is that easy
>>> to
>>> do? Good suggestion? Bad suggestion?
>>>
>>> Thanks,
>>>
>>> -Luther
>>>
>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: ordering of stylesheets
Posted by "Filip S. Adamsen" <fs...@fsadev.com>.
Hi,
Using an XHTML DTD isn't enough to make Tapestry output correct XHTML.
See http://wiki.apache.org/tapestry/Tapestry5HowToXhtml for more about
that. It needs to be updated, though, something I might do later today
if I get time.
Wrt. @IncludeStylesheet, there's an alternative that lets you specify
the media type of the stylesheet - use RenderSupport#addStylesheetLink.
-Filip
On 2008-09-14 15:46, Luther Baker wrote:
> Oh yes ... and out of the box ... it'd be nice if Tapestry properly closed
> <link> and <meta> tags.
>
> (There are several more attributes to a link tag ... are those possible
> @IncludeStylesheet annotation parameters?)
>
> Hey ... just suggestions if anyone's taking notes.
>
> Generally love the concept and current implementation.
>
> -Luther
>
>
>
> On Sun, Sep 14, 2008 at 8:42 AM, Luther Baker <lu...@gmail.com> wrote:
>
>> I have a small question. I have a component (htmlWrapper) that encapsulates
>> each of my pages. I guess you'd call it a custom layout component. Each of
>> my pages generally do something like
>>
>> <t:htmlWrapper ...>
>> body here
>> </t:htmlWrapper>
>>
>> This layout component includes basic or common css stylesheets. *My
>> problem is this: I want each individual page to be able to add and override
>> styles based on this common stylesheet.* Unfortunately, I don't see a
>> definitive way to ORDER the stylesheets in the render process. At least, not
>> declaratively or from the leaf nodes (*.tml or Java files associated with
>> page or component).
>>
>> For instance, my personal thoughts were that stylesheets in the *.tml files
>> should come first.
>>
>> a) individual pages generally want to OVERRIDE the more generic template
>> styles sheets. page style sheets should come last.
>> b) if you use a layout component (which I have to guess most everyone
>> does), the pages them selves don't even have a <head> section and so would
>> generally not include stylesheets in the *.tml file. My actually pages
>> generally use the stylesheet annotation in the java files. Include those
>> last.
>>
>> So that was my blatantly simple thought. It may not work in every case but
>> it would create some sense of order. Stylsheets in TML files always preceed
>> stylesheets defined in Java files. I guess this could be simplified to
>> "stylesheets from Java files should always be LAST in the <head> section.
>>
>> If that is hard to do ... another thought would be to have a custom
>> component rendered in the <head> section that would be substituted with Java
>> stylesheets includes. Then I could literally put it wherever I wanted.
>> Unfortunately, this comes back to my earlier post - that the <head> section
>> really gets rewritten in a subtley non-satisafactory way. If using XHTML
>> DOCTYPE, when generating the <head> tag,
>>
>> It'd be nice if, out of the box, Tapestry would:
>>
>> a) include include ContentType meta tag first, the language and content
>> type should/must preceed all other content in the file
>> b) include all javascript files in the head, I believe it is invalid per
>> the XHTML DTD to place <script> tags in the <body> but if not,
>> conventionally, <script> tags are supposed to reside only in <head>
>> c) predictably order the stylessheets so that page specific css files can
>> predicably override common or shared css files.
>>
>> Obviously, just my $0.02.
>>
>> So back to my early question about ordering stylesheets ... is that easy to
>> do? Good suggestion? Bad suggestion?
>>
>> Thanks,
>>
>> -Luther
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: ordering of stylesheets
Posted by Luther Baker <lu...@gmail.com>.
Oh yes ... and out of the box ... it'd be nice if Tapestry properly closed
<link> and <meta> tags.
(There are several more attributes to a link tag ... are those possible
@IncludeStylesheet annotation parameters?)
Hey ... just suggestions if anyone's taking notes.
Generally love the concept and current implementation.
-Luther
On Sun, Sep 14, 2008 at 8:42 AM, Luther Baker <lu...@gmail.com> wrote:
> I have a small question. I have a component (htmlWrapper) that encapsulates
> each of my pages. I guess you'd call it a custom layout component. Each of
> my pages generally do something like
>
> <t:htmlWrapper ...>
> body here
> </t:htmlWrapper>
>
> This layout component includes basic or common css stylesheets. *My
> problem is this: I want each individual page to be able to add and override
> styles based on this common stylesheet.* Unfortunately, I don't see a
> definitive way to ORDER the stylesheets in the render process. At least, not
> declaratively or from the leaf nodes (*.tml or Java files associated with
> page or component).
>
> For instance, my personal thoughts were that stylesheets in the *.tml files
> should come first.
>
> a) individual pages generally want to OVERRIDE the more generic template
> styles sheets. page style sheets should come last.
> b) if you use a layout component (which I have to guess most everyone
> does), the pages them selves don't even have a <head> section and so would
> generally not include stylesheets in the *.tml file. My actually pages
> generally use the stylesheet annotation in the java files. Include those
> last.
>
> So that was my blatantly simple thought. It may not work in every case but
> it would create some sense of order. Stylsheets in TML files always preceed
> stylesheets defined in Java files. I guess this could be simplified to
> "stylesheets from Java files should always be LAST in the <head> section.
>
> If that is hard to do ... another thought would be to have a custom
> component rendered in the <head> section that would be substituted with Java
> stylesheets includes. Then I could literally put it wherever I wanted.
> Unfortunately, this comes back to my earlier post - that the <head> section
> really gets rewritten in a subtley non-satisafactory way. If using XHTML
> DOCTYPE, when generating the <head> tag,
>
> It'd be nice if, out of the box, Tapestry would:
>
> a) include include ContentType meta tag first, the language and content
> type should/must preceed all other content in the file
> b) include all javascript files in the head, I believe it is invalid per
> the XHTML DTD to place <script> tags in the <body> but if not,
> conventionally, <script> tags are supposed to reside only in <head>
> c) predictably order the stylessheets so that page specific css files can
> predicably override common or shared css files.
>
> Obviously, just my $0.02.
>
> So back to my early question about ordering stylesheets ... is that easy to
> do? Good suggestion? Bad suggestion?
>
> Thanks,
>
> -Luther
>
>