You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by devel - Fashion Content <de...@fashioncontent.com> on 2006/07/31 14:09:23 UTC

Idea for @Shell improvement

I have been using my own custom Shell component for a while now, and have come up with an improvement along the lines of the AjaxDelegate.

I think a Cache flagging mechanism would be very good, but I will put that in a separate suggestion.

On most sites you would want a common setup for :

doctype
stylesheet
stylesheets

You might even want to implement a skinnable concept and vary the stylesheets depending on the user.

How about new parameter IShellDefaults getShellDefaults().

interface IShellDefault {
    String getDoctype();
    String[] getBaseStylesheets(); // Always used
    String[] getStylesheets(); // Used if none are specified
    IDelegate getDelegate(String pageName); // Can be used for favicon etc   
}

I can submit a patch if my approach sounds good.

Henrik

Re: Idea for @Shell improvement

Posted by devel - Fashion Content <de...@fashioncontent.com>.
The suggestion didn't really introduce anything that isn't already in the 
@Shell component. It merely allows
you to have common values across pages.

----- Original Message ----- 
From: "Henri Dupre" <he...@gmail.com>
To: "Tapestry development" <de...@tapestry.apache.org>
Sent: Monday, July 31, 2006 6:58 PM
Subject: Re: Idea for @Shell improvement


> On 7/31/06, devel - Fashion Content <de...@fashioncontent.com> wrote:
>
>> Ew, I find @Border an abomination tbh.
>> 1) It breaks up the .html so it no longer looks like a normal html page
>
>
> We have
> <body jwcid="$content$">
> <span jwcid="@Border" title="...">
> ...
> </span>
> </body>
> This doesn't break at all the html.
> The idea is to use encapsulation here instead of doing everything in the
> @Shell.
>
>
>
>> 2) It assumes that header remains the same across pages.
>
>
> Not at all. You can add parameters and logic to your "border" component to
> setup any defaults you like on the @Shell.
>
> -- 
> Henri Dupre
> Actualis Center
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Re: Idea for @Shell improvement

Posted by Henri Dupre <he...@gmail.com>.
On 7/31/06, devel - Fashion Content <de...@fashioncontent.com> wrote:

> Ew, I find @Border an abomination tbh.
> 1) It breaks up the .html so it no longer looks like a normal html page


We have
<body jwcid="$content$">
<span jwcid="@Border" title="...">
...
</span>
</body>
This doesn't break at all the html.
The idea is to use encapsulation here instead of doing everything in the
@Shell.



> 2) It assumes that header remains the same across pages.


Not at all. You can add parameters and logic to your "border" component to
setup any defaults you like on the @Shell.

-- 
Henri Dupre
Actualis Center

Re: Idea for @Shell improvement

Posted by devel - Fashion Content <de...@fashioncontent.com>.
Ew, I find @Border an abomination tbh.
1) It breaks up the .html so it no longer looks like a normal html page
2) It assumes that header remains the same across pages.

Or at least it seemed that way to me when I started using Tap.

Henrik
----- Original Message ----- 
From: "Henri Dupre" <he...@gmail.com>
To: "Tapestry development" <de...@tapestry.apache.org>
Sent: Monday, July 31, 2006 5:58 PM
Subject: Re: Idea for @Shell improvement


> Not sure what you mean... Can't you create your own @Border component that
> wraps a @Shell with your defaults?
>
>
> On 7/31/06, devel - Fashion Content <de...@fashioncontent.com> wrote:
>>
>> I have been using my own custom Shell component for a while now, and have
>> come up with an improvement along the lines of the AjaxDelegate.
>>
>> I think a Cache flagging mechanism would be very good, but I will put 
>> that
>> in a separate suggestion.
>>
>> On most sites you would want a common setup for :
>>
>> doctype
>> stylesheet
>> stylesheets
>>
>> You might even want to implement a skinnable concept and vary the
>> stylesheets depending on the user.
>>
>> How about new parameter IShellDefaults getShellDefaults().
>>
>> interface IShellDefault {
>>    String getDoctype();
>>    String[] getBaseStylesheets(); // Always used
>>    String[] getStylesheets(); // Used if none are specified
>>    IDelegate getDelegate(String pageName); // Can be used for favicon etc
>> }
>>
>> I can submit a patch if my approach sounds good.
>>
>> Henrik
>>
>>
>
>
> -- 
> Henri Dupre
> Actualis Center
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Re: Idea for @Shell improvement

Posted by Henri Dupre <he...@gmail.com>.
Not sure what you mean... Can't you create your own @Border component that
wraps a @Shell with your defaults?


On 7/31/06, devel - Fashion Content <de...@fashioncontent.com> wrote:
>
> I have been using my own custom Shell component for a while now, and have
> come up with an improvement along the lines of the AjaxDelegate.
>
> I think a Cache flagging mechanism would be very good, but I will put that
> in a separate suggestion.
>
> On most sites you would want a common setup for :
>
> doctype
> stylesheet
> stylesheets
>
> You might even want to implement a skinnable concept and vary the
> stylesheets depending on the user.
>
> How about new parameter IShellDefaults getShellDefaults().
>
> interface IShellDefault {
>    String getDoctype();
>    String[] getBaseStylesheets(); // Always used
>    String[] getStylesheets(); // Used if none are specified
>    IDelegate getDelegate(String pageName); // Can be used for favicon etc
> }
>
> I can submit a patch if my approach sounds good.
>
> Henrik
>
>


-- 
Henri Dupre
Actualis Center