Sitemesh 3 ?

[Paul Hammant-3]

Folks,

I'm itching for multi-stage Sitemesh.  Something that can decorate a page, and have that result decorated.

We use Sitemesh in the ThoughtWorks website (for now at least).

See :

   http://www.thoughtworks.com/

   then http://www.thoughtworks.com/who-we-are/

   then http://www.thoughtworks.com/who-we-are/our-culture.html

It is nesting I want you see.  Something with some directory based matching rules.

Does anyone else need the same thing?

Regards,

- Paul

[Paul Hammant-3]

On Dec 17, 2008, at 5:48 PM, Ben Hu wrote:

> multi-stage sitemesh does sound interesting.
>
> sitemesh last release was 2 years ago. wondering if there will be  
> new stable release coming out!

The currrent release is very stable, and the dev team has the view  
that there are no pressing issues that would require a new release.

"It just works" is the eight year view of Sitemesh.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Joe Walnes]

We investigated multi-stage processing a few years back but couldn't
come up with a compelling usage scenario. Paul, could you go into some
more depth about what it is you'd like to achieve - examples would be
be ideal.

thanks
-Joe

On Wed, Dec 24, 2008 at 9:18 PM, Paul Hammant <paul@...> wrote:

>
> On Dec 17, 2008, at 5:48 PM, Ben Hu wrote:
>
>> multi-stage sitemesh does sound interesting.
>>
>> sitemesh last release was 2 years ago. wondering if there will be new
>> stable release coming out!
>
> The currrent release is very stable, and the dev team has the view that
> there are no pressing issues that would require a new release.
>
> "It just works" is the eight year view of Sitemesh.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Paul Hammant-3]

(Groovy or JRuby , with ref to http://www.thoughtworks.com/ )

tomcat {
     webapp(vhost:"thoughtworks.com") {
         decorate(directory:"/", decorator:"rootDecorator.jsp")
         decorate(directory:"/who-we-are/", decorator:"who-we-are-
decorator.ftl")
         decorate(directory:"/what-we-do/", decorator:"wot-we-do-
decorator.ftl")
         // etc
        filter ( /*other filter */ )
        servlet ( /*other servlet */ )
     }
     webapp(vhost:"studios.thoughtworks.com") {
         decorate(directory:"/", decorator:"root.jsp")
         decorate(directory:"/products/", decorator:"prodcts.jsp")
         // etc
        filter ( /*other filter */ )
        servlet ( /*other servlet */ )
     }
}

So inside SM, there is some isAlreadyDecorated() functionality that  
needs to go, I think.
Plus with a multi-site configuration such as the above, you'll need to  
do less of the singleton-esque caching of decoration for one SM jar,  
as it may transcend multiple sites in the next Java webapp era.

I'm only showing decorators that match against a web directories  
above, but what I'm trying to say is that this would feel more modular  
or direct, if the configuration (etc) were inline with implicit filter  
declaration.  It may be just as appropriate to see this for other  
mapper strategies.  With IoC, configuration is given to you, you don't  
find it yourself.  It seems to me that decorators.xml and sitemesh.xml  
could killed for Sitemesh3 codeline.

Anyways, back to the turkey and grog...

Regards,

- Paul

On Dec 25, 2008, at 11:11 AM, Joe Walnes wrote:

> We investigated multi-stage processing a few years back but couldn't
> come up with a compelling usage scenario. Paul, could you go into some
> more depth about what it is you'd like to achieve - examples would be
> be ideal.
>
> thanks
> -Joe
>
> On Wed, Dec 24, 2008 at 9:18 PM, Paul Hammant <paul@...>  
> wrote:
>>
>> On Dec 17, 2008, at 5:48 PM, Ben Hu wrote:
>>
>>> multi-stage sitemesh does sound interesting.
>>>
>>> sitemesh last release was 2 years ago. wondering if there will be  
>>> new
>>> stable release coming out!
>>
>> The currrent release is very stable, and the dev team has the view  
>> that
>> there are no pressing issues that would require a new release.
>>
>> "It just works" is the eight year view of Sitemesh.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Joe Walnes]

Very nice.

Taking a step back, SiteMesh consists of a few components (e.g.
filter, request wrapper, parser, mapper, config reader, decorator
bindings, etc) which are assembled together to suit the needs of the
majority of users - those who just want to drop it in as a filter to
web.xml.

However, it's possible build your own layer for assembling it in a
different environment (e.g. through a declarative IoC container).

As a first step, I suggest replacing
com.opensymphony.sitemesh.webapp.SiteMeshFilter with your own class.
This class contains the default assembly of components and basic flow
of control. It delegates all the hard word to other components.

A custom implementation of this could:
* Receive all its dependencies, configuration, etc from an IoC container.
* Support multiple decoration stages.

This brings be back to the thing that we got stuck last time around...
what would multiple decoration stages look like anyway? SM works
because it's generally pretty safe to merge vanilla content with a
stylized decorator. However, if merging multiple decorators, you can
easily get into markup conflicts and lose flexibility with ordering.
So, please could you give an example, in the form of actual page
markup of what you'd like each phase in the transformation to do?

> So inside SM, there is some isAlreadyDecorated() functionality that needs to
> go, I think.

You're right. This is in SiteMeshFilter, which you would be replacing anyway.

> Plus with a multi-site configuration such as the above, you'll need to do
> less of the singleton-esque caching of decoration for one SM jar, as it may
> transcend multiple sites in the next Java webapp era.

The only thing that is cached is the config, which you would be
replacing anyway. SM is already friendly to being used cross web-apps,
in both shared and isolated classloader configurations.

> I'm only showing decorators that match against a web directories above, but
> what I'm trying to say is that this would feel more modular or direct, if
> the configuration (etc) were inline with implicit filter declaration.  It
> may be just as appropriate to see this for other mapper strategies.  With
> IoC, configuration is given to you, you don't find it yourself.  It seems to
> me that decorators.xml and sitemesh.xml could killed for Sitemesh3 codeline.

I agree - mostly ;). I much prefer the more inline, composite style
declarative syntax, such as the example you supplied, and would
personally choose to use that, if my supporting web-app infrastructure
supported it. I would be in favor of doing whatever possible to make
it easy to use SM in this kind of environment. However, the vast
majority of users will still be using plain old web-apps, with
web.xml, etc and I don't want to remove this functionality for them,
or worse, couple them to another framework.

> Anyways, back to the turkey and grog...

My stomach hurts.

-Joe

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Paul Hammant-3]

Thinking about this... yes a custom filter would do.

I might make one that automatically applied every page to a decorator  
of a certain name in the same directory, then recursed to root  
applying the decorators it encountered as well.  It would not be  
perfect as those decorators would feel like they are relative in terms  
of URL (image/stylesheet refs), but would actually be absolute.

I'll come back with something that is working.

Regards,

- Paul

On Dec 26, 2008, at 7:52 AM, Joe Walnes wrote:

> Very nice.
>
> Taking a step back, SiteMesh consists of a few components (e.g.
> filter, request wrapper, parser, mapper, config reader, decorator
> bindings, etc) which are assembled together to suit the needs of the
> majority of users - those who just want to drop it in as a filter to
> web.xml.
>
> However, it's possible build your own layer for assembling it in a
> different environment (e.g. through a declarative IoC container).
>
> As a first step, I suggest replacing
> com.opensymphony.sitemesh.webapp.SiteMeshFilter with your own class.
> This class contains the default assembly of components and basic flow
> of control. It delegates all the hard word to other components.
>
> A custom implementation of this could:
> * Receive all its dependencies, configuration, etc from an IoC  
> container.
> * Support multiple decoration stages.
>
> This brings be back to the thing that we got stuck last time around...
> what would multiple decoration stages look like anyway? SM works
> because it's generally pretty safe to merge vanilla content with a
> stylized decorator. However, if merging multiple decorators, you can
> easily get into markup conflicts and lose flexibility with ordering.
> So, please could you give an example, in the form of actual page
> markup of what you'd like each phase in the transformation to do?
>
>> So inside SM, there is some isAlreadyDecorated() functionality that  
>> needs to
>> go, I think.
>
> You're right. This is in SiteMeshFilter, which you would be  
> replacing anyway.
>
>> Plus with a multi-site configuration such as the above, you'll need  
>> to do
>> less of the singleton-esque caching of decoration for one SM jar,  
>> as it may
>> transcend multiple sites in the next Java webapp era.
>
> The only thing that is cached is the config, which you would be
> replacing anyway. SM is already friendly to being used cross web-apps,
> in both shared and isolated classloader configurations.
>
>> I'm only showing decorators that match against a web directories  
>> above, but
>> what I'm trying to say is that this would feel more modular or  
>> direct, if
>> the configuration (etc) were inline with implicit filter  
>> declaration.  It
>> may be just as appropriate to see this for other mapper  
>> strategies.  With
>> IoC, configuration is given to you, you don't find it yourself.  It  
>> seems to
>> me that decorators.xml and sitemesh.xml could killed for Sitemesh3  
>> codeline.
>
> I agree - mostly ;). I much prefer the more inline, composite style
> declarative syntax, such as the example you supplied, and would
> personally choose to use that, if my supporting web-app infrastructure
> supported it. I would be in favor of doing whatever possible to make
> it easy to use SM in this kind of environment. However, the vast
> majority of users will still be using plain old web-apps, with
> web.xml, etc and I don't want to remove this functionality for them,
> or worse, couple them to another framework.
>
>> Anyways, back to the turkey and grog...
>
> My stomach hurts.
>
> -Joe
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...