You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Greg Reddin <gr...@apache.org> on 2006/04/28 22:03:47 UTC

[Standalone Tiles] Progress

I've added a preliminary version of a TilesContext interface and  
refactored the core API to use it.  The interface is a first attempt  
at extracting the Servlet API dependencies.   Here are some more  
details:

I debated about whether to model TilesContext after Commons-Chain's  
WebContext or JSF's ExternalContext.  WebContext seemed a bit more  
applicable so I started with a very similar interface.  I then added  
a few more methods mostly modeled after ExternalContext.  I created a  
factory and a Servlet-based implementation just to get the tests to  
pass.  I suspect the factory and the way it's being used to change  
significantly after I look further at the way Faces and Chain use  
their context classes in various environments.  Note that I ran out  
of time before I had a chance to look at these other examples, so if  
you look at what I just committed and inherently see a better way,  
please share.

I have not tested this at all other than the provided unit tests, so  
it probably doesn't work :-)  I'm just trying to push something  
through before I have to take off for the weekend so some progress is  
being made.  I'd love it if some others would look at my most recent  
commit and give me some advice on how to improve it.  Starting next  
week I hope to be able to flesh this all out further.

This is the last refactoring step that is needed before the  
Standalone Tiles API will be stable.  Yippeeeee!  If I don't respond  
to any emails for a while it's because I'm going out of town for the  
weekend, but I'll check back in on Monday.

Greg

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


Re: [Standalone Tiles] Progress

Posted by Greg Reddin <gr...@apache.org>.
Oh yeah, hidden in that last commit... Since I was changing the  
Controller interface anyway, I went ahead and got rid of the perform 
() method. It was deprecated and needed to go away eventually.   
Please let me know if anyone has serious issues with that.

Greg

On Apr 28, 2006, at 3:03 PM, Greg Reddin wrote:

> I've added a preliminary version of a TilesContext interface and  
> refactored the core API to use it.  The interface is a first  
> attempt at extracting the Servlet API dependencies.   Here are some  
> more details:
>
> I debated about whether to model TilesContext after Commons-Chain's  
> WebContext or JSF's ExternalContext.  WebContext seemed a bit more  
> applicable so I started with a very similar interface.  I then  
> added a few more methods mostly modeled after ExternalContext.  I  
> created a factory and a Servlet-based implementation just to get  
> the tests to pass.  I suspect the factory and the way it's being  
> used to change significantly after I look further at the way Faces  
> and Chain use their context classes in various environments.  Note  
> that I ran out of time before I had a chance to look at these other  
> examples, so if you look at what I just committed and inherently  
> see a better way, please share.
>
> I have not tested this at all other than the provided unit tests,  
> so it probably doesn't work :-)  I'm just trying to push something  
> through before I have to take off for the weekend so some progress  
> is being made.  I'd love it if some others would look at my most  
> recent commit and give me some advice on how to improve it.   
> Starting next week I hope to be able to flesh this all out further.
>
> This is the last refactoring step that is needed before the  
> Standalone Tiles API will be stable.  Yippeeeee!  If I don't  
> respond to any emails for a while it's because I'm going out of  
> town for the weekend, but I'll check back in on Monday.
>
> Greg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


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


Re: [Standalone Tiles] Progress

Posted by Antonio Petrelli <br...@tariffenet.it>.
Greg Reddin ha scritto:
> I've added a preliminary version of a TilesContext interface and 
> refactored the core API to use it. .
> ....
> Note that I ran out of time before I had a chance to look at these 
> other examples, so if you look at what I just committed and inherently 
> see a better way, please share.
Hi Greg
I am working on an idea that involves Contexts and Scopes (in fact the 
product I want to release will be called "Scopes" ;-) ) without being 
tied to any framework.
What I created is a "State" that comprises a certain number of 
"Contexts" that have a similar API to ServletRequest, HttpSession and 
ServletContext (I mean they all have "getAttribute" and "setAttribute" 
methods).
"State.getContext(String contextName)" method is used to retrieve the 
context, i.e. you can call it such as:
state.getContext("request") to get request context.
The engine creates the State through the use of a serlvet filter and 
uses a wrapped HttpServletRequest to deliver it to servlets.
I don't know if it is useful. You know, I wish to publish it with Apache 
License on Sourceforge but I still did not register a project for it, 
because I wanted to write a bit of docs first. But anyway if you are 
interested on it I can post it ASAP.
Anyway I really liked the idea of TilesContext. Just a thought... what 
do you think about using it in ComponentDefinitions.getDefinition 
methods? I noticed that your TilesContext has a map for headers, that I 
use to read for detecting the device....
Ciao
Antonio

P.S. I also managed to add "window" scope but that is another story.

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