The future of actions (RE: Adding new Struts features/sub-projects (was [Bug 28609] - Scriptable Actions Support))

[Joe Germuska <Jo...@Germuska.com>]

I don't think you're heretical at all, Martin.  I was at the 
Wisconsin Java Software Symposium a couple of weeks ago, and between 
the sessions on WebWork and Spring and on writing testable Struts 
code, I came away convinced that changing how Actions work was a high 
priority.

And, along the lines of what David says, I've been thinking about and 
writing about ideas for doing view-preparation in Struts for a while.

To me these are two separate pieces -- I'm not sure if David and I 
see things differently, or if that's just how I read his words.

I think we can make progress in this direction in a pre-2.0 time 
frame.  In fact, given the way we work, I'm beginning to wonder if it 
makes sense to declare a 2.0 revolution; I think we can do a lot with 
incremental changes on the 1.x line.

But the first steps are to get 1.2.1 out the door and get the TLP web 
site in order.  Is there anything I can do to help with 
struts.apache.org?   I don't really have a sense of the tasks, but if 
someone else does and wants to just dole a few out, I could try to 
help move that forward...

Joe


>--- Martin Cooper <ma...@apache.org> wrote:
>
><snip/>
>
>>  Hmm. These days, I'm leaning towards thinking of Actions as something we
>>  retain for backwards compatibility only, once we're in a Struts 2.0
>>  world,
>>  so I'm not sure I'd consider a scriptable action, let alone just a plain
>>  Action, as something that would go in the core.
>>
>>  I should probably elaborate a little on the perhaps heretical statement
>>  above. ;-)
>>
>>  For a long time now, I have considered Actions as almost an
>  > anti-pattern.


At 6:12 AM -0700 4/28/04, David Graham wrote:
>I agree; I always found Tiles' Controllers to be more useful than Actions
>for setting up a view because you attach the preparation code to the
>actual view instead of trying to remember which URL causes this view to be
>displayed.  However, you can't always use a Tiles Controller and need an
>Action to make decision logic.  It would be nice to have a view
>preparation system in the core and move away from Actions.

-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com    
       "Imagine if every Thursday your shoes exploded if you tied them 
the usual way.  This happens to us all the time with computers, and 
nobody thinks of complaining."
             -- Jef Raskin

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

Re: The future of actions (RE: Adding new Struts features/sub-projects (was [Bug 28609] - Scriptable Actions Support))

[Michael McGrady <mi...@michaelmcgrady.com>]

+1

At 09:06 AM 4/28/2004, Joe Germuska wrote:
>I don't think you're heretical at all, Martin.  I was at the Wisconsin 
>Java Software Symposium a couple of weeks ago, and between the sessions on 
>WebWork and Spring and on writing testable Struts code, I came away 
>convinced that changing how Actions work was a high priority.
>
>And, along the lines of what David says, I've been thinking about and 
>writing about ideas for doing view-preparation in Struts for a while.
>
>To me these are two separate pieces -- I'm not sure if David and I see 
>things differently, or if that's just how I read his words.
>
>I think we can make progress in this direction in a pre-2.0 time 
>frame.  In fact, given the way we work, I'm beginning to wonder if it 
>makes sense to declare a 2.0 revolution; I think we can do a lot with 
>incremental changes on the 1.x line.
>
>But the first steps are to get 1.2.1 out the door and get the TLP web site 
>in order.  Is there anything I can do to help with struts.apache.org?   I 
>don't really have a sense of the tasks, but if someone else does and wants 
>to just dole a few out, I could try to help move that forward...
>
>Joe
>
>
>>--- Martin Cooper <ma...@apache.org> wrote:
>>
>><snip/>
>>
>>>  Hmm. These days, I'm leaning towards thinking of Actions as something we
>>>  retain for backwards compatibility only, once we're in a Struts 2.0
>>>  world,
>>>  so I'm not sure I'd consider a scriptable action, let alone just a plain
>>>  Action, as something that would go in the core.
>>>
>>>  I should probably elaborate a little on the perhaps heretical statement
>>>  above. ;-)
>>>
>>>  For a long time now, I have considered Actions as almost an
>>  > anti-pattern.
>
>
>At 6:12 AM -0700 4/28/04, David Graham wrote:
>>I agree; I always found Tiles' Controllers to be more useful than Actions
>>for setting up a view because you attach the preparation code to the
>>actual view instead of trying to remember which URL causes this view to be
>>displayed.  However, you can't always use a Tiles Controller and need an
>>Action to make decision logic.  It would be nice to have a view
>>preparation system in the core and move away from Actions.
>
>--
>Joe Germuska
>Joe@Germuska.com
>http://blog.germuska.com
>       "Imagine if every Thursday your shoes exploded if you tied them the 
> usual way.  This happens to us all the time with computers, and nobody 
> thinks of complaining."
>             -- Jef Raskin
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>

TLP layout (was Re: The future of actions)

[Ted Husted <hu...@apache.org>]

On Wed, 28 Apr 2004 11:06:13 -0500, Joe Germuska wrote:
> But the first steps are to get 1.2.1 out the door and get the TLP
> web site in order.  Is there anything I can do to help with
> struts.apache.org?   I don't really have a sense of the tasks, but
> if someone else does and wants to just dole a few out, I could try
> to help move that forward...

One of the next big steps will be to prototype a restructured code tree for CVS and post it where others can review it. The prototype would only need to be a filesystem, and wouldn't have to worry about CVS history. Though, we'd want to retain that when we did it for real on the server.

The general idea is that we want to subdivide the project into subprojects, each of which would represent a deliverable or Maven artifact. So at the top, there would probably something like: 

* core (including tiles and validator for now)
* apps
* site
* whiteboard (or "sandbox")

* opt-taglib
* opt-el
* opt-faces

We'd want to follow the Maven project layout recommendations for each deliverable. This will be the easiest for everyone to grok in the longrun.

http://maven.apache.org/reference/dirlayout.html

So, under each top-level directory, we would find a layout like

/src
�- java
�- test
�- webapp

/xdocs

/target (generated)
- *.jar
- distributions
- docs
- site
- ...

The example applications tree might be a tad different. Here we might want a master apps directory, with a directory for each application beneath that. This makes it easy for the apps to extend a common Maven project.xml. We could still offer a single zip/tarball with all the applications WARs within.

/apps
�- examples
�- mailreader
�- tilesPortal
�- userdb

This is what I've started to over in Commons Chain, since I envision having a couple of sample applications (using either Servlets or Filters). The Struts one I'd want to bring over here, once we've added a dependency on Chain.

As to "userDb", the UserDatabase code in the MailReader is getting reused in multiple applications these days, so we should make it a separate deliverable.

-Ted.



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