Ted Husted wrote:
On Fri, 12 Mar 2004 10:30:08 -0600, Hookom, Jacob wrote:
What I would like to do is develop Struts 2.0 test-first. The idea being we cold start with a simple application and write just enough of 2.0 to develop the first page (or story). Then just enough to develop the second page,
Thank you very much for doing this. I've looked at implementing Tiles
support on several occasions and just haven't had the time to do it.
Soon as I get a chance I'll download it and see how it works.
Greg
Joe Germuska wrote:
I just committed a new command and a support class to the struts-cha
Check here:
http://jakarta.apache.org/struts/userGuide/dev_tiles.html
Look at the bottom of the page.
Greg
Sean Gunn wrote:
Anyone know of a mirror for tilesAdvancedFeatures.pdf?
It is referenced in the tiles guide:
http://jakarta.apache.org/struts/userGuide/dev_tiles.html
as being at
http://ww
David Graham wrote:
--- Greg Reddin <[EMAIL PROTECTED]> wrote:
BTW, there's about five ways to submit code here. Would you prefer an
email attachment, a bugzilla ticket, or some other way?
Bugzilla with attached cvs diff -u formatted patches.
But, this is new stuff, nothing to di
The next step might be to try and integrate something like Struts
Workflow and/or Tiles into the RequestProcessor chain and see what the
various Chains look like.
I get about a day every three weeks to look at this, but Tiles is what
I'm working on. I'll share early and often.
BTW, there's abo
Ok, thanks for the clarification. So you're not suggesting that the
branching thing was a wholesale bad idea that should never be used. You
just prefer the "state checking" method for validation. I'm cool with that.
Greg
Craig R. McClanahan wrote:
Greg Reddin wrote:
I&#
I'm sorry to bring back up a discussion that's been hashed out already,
but there's something I still don't understand...
I can see why it's better for every command in the chain to be executed
rather than executing a "sub-chain" based on some condition. I can see
the correlation of the sub-ch
til;
/**
* Determine if the ForwardConfig invokes a Tiles Definition and
* invoke it.
*
* @author Greg Reddin
* @version $Revision: 1.1 $ $Date: 2003/09/26 21:53:00 $
*/
public class ProcessTilesDefinition extends AbstractPerformForward {
// --
There's a "conditional behavior" use case in the existing code as well;
when validation fails, we want to redisplay the input form. Originally,
I modelled this command as a Chain that conditionally executed its child
commands, but that seemed a little hokey. Now, this command definition
says:
I'm trying to write a Command or set of Commands that will process a
Tiles definition to help complete the 1.x-compatible chained request
processor. I've got something working, but I would like some community
input before I submit it.
First, I created another subclass of AbstractPerformForward
ntainer. You can customize the request processing behavior by
* subclassing this class and overriding the method(s) whose behavior you are
* interested in changing.
*
* @author Craig R. McClanahan
* @author Cedric Dumoulin
* @author Greg Reddin
*
* @version
Yeah, I was actually thinking 1.x when I read and wrote 1.1 :-)
Thanks for clarifying.
Ted Husted wrote:
>> (although for 1.1 we'd probably implement all this inside a new one
>> that simply replaces the process() method with the appropriate chain
>> lookup and execution.)
For clarity, we probab
If we were to build everything on such a structure, configuring a Struts
app would be mostly done by letting Struts load its standard definitions
of all the chains (from some internal-to-Struts XML resource), then
letting the application load its own config files -- possibly overriding
the standard
I was mainly trying to be sure that it was technically feasible to use
commos-chain for this kind of decomposition, and that seems to be the
case. For actually implementing a 1.1-compatible layer, we'd need more
than just me working on the code. But I wanted to share my initial
progress to see if
Not only "had in mind" but "already partly done". There would no longer
be any direct calls to each "process" method -- instead, they would all be
commands in a chain that is preconfigured by Struts (and then optionally
specialized by the app developer).
So is this already partialy implemented in
Oops sorry. I sent this email to the wrong address.
Greg Reddin wrote:
I'm going through the process right now of building all the audio tools.
I'm also documenting every step of it, and hope to publish it in some
way when I get done. We'll see how it goes.
Greg
David G
I'm going through the process right now of building all the audio tools.
I'm also documenting every step of it, and hope to publish it in some
way when I get done. We'll see how it goes.
Greg
David Graham wrote:
I would prefer to add ParameterDispatchAction now and defer a decision
about
merg
There's a bug report regrading this problem. If you can, download the
patch and see if it helps.
http://issues.apache.org/bugzilla/show_bug.cgi?id=17562
Greg
On Tue, 2003-03-18 at 16:10, Anand Joshi wrote:
>
>
>
>
> Hello,
> I am using tiles:insert tag inside logic:iterate tag with struts 1
We're at the end of the process of writing a pretty large app using Struts with
XSL instead of JSP. Like you, most of our data was represented as XML
internally. However, if I was doing it again, I'd probably use JSP.
Here's what we've done.
We get XML data from the backend. For each request w
19 matches
Mail list logo
