You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Frank W. Zammetti" <fz...@omnytex.com> on 2007/12/13 07:12:26 UTC
Result types for S1
So, now that I've gotten my build problems sorted out, I was able to
make some quick progress on what I wanted to work on, enough that I want
to run this by everyone before I spit, polish and submit patches.
Ted and I were discussing some ideas at The Ajax Experience back in
October, specifically on how we could make S1 a little more
AJAX-friendly and useful to developers doing RIA development. One of
the ideas I had was the ability to have, essentially, "result types" in
S1, ala S2.
As a concrete example, say I have an Action that does this at the end:
return mapping.findForward("JSONResultType");
That mapping name would be a value specially recognized by Struts. The
result of doing that would be that the response is a JSON representation
of the appropriate ActionForm. One can easily imagine an XMLResultType,
a FreemarkerResultType, a DataVisionResultType, and so on.
Note that the developer *does not* need to add any configuration to
struts-config, they have only to specify that forward name, and the
ActionForm to JSON conversion is automatic.
I have this JSONResultType working right now, and it turns out it's a
minimally intrusive change to the S1 code base overall, consisting of:
* Some frankly minor changes to two Chain Commands
* The addition of a new package containing one new class (the class that
actually generates the result output, more to follow as new result types
are implemented)
* Some new dependencies: one during build (json-lib), and four at
runtime (if using that result type): Commons Collections, Commons Lang,
JSON-Lib and EZMorph).
To be clear, this code isn't complete and ready immediately, it's POC
grade right now, but it's not too far off either, maybe an hour or two
worth of polishing.
So, does anyone else think this is a worthwhile exercise? I certainly
think it is: the ability to have automatic conversion of an ActionForm
to JSON, XML, or whatever else, means S1 can become a true service
provider for AJAX-based clients with no real effort on the developers'
parts. It's not a huge change to the Struts code base, doesn't break
compatibility in any way (I suppose unless someone happens to have the
exact forward names I'm proposing here in their app already), and aside
from the added dependencies, I don't see a down-side.
Thoughts?
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Result types for S1
Posted by Antonio Petrelli <an...@gmail.com>.
2007/12/13, Paul Benedict <pb...@apache.org>:
> I don't think it's a good idea to repurpose the <forward> attribute. It's
> not identical to <result> in s2 with a type. I would truly recommend a
> different kind of tag here.
In fact a <forward> is a <result>, but not the opposite.
Probably a <result type="forward"> could be a synonym of <forward>...
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Result types for S1
Posted by Antonio Petrelli <an...@gmail.com>.
2007/12/13, Frank W. Zammetti <fz...@omnytex.com>:
> Antonio Petrelli wrote:
> > 2007/12/13, Frank W. Zammetti <fz...@omnytex.com>:
> >> if we simply say that if it DOESN'T begin with a slash,
> >> then it means something else, be it a template or class, or something
> >> else, how would you feel about that?
> >
> > It seems like Tiles definition names...
>
> Are you saying there would be a conflict then? I admit I'm not at all
> familiar with the internals of Tiles (or Tiles in general, at least not
> the most recent versions), so I can't say.
I don't think so: the Tiles plugin first parses the forward name. If
it finds it is a name of a definition, then it renders it, otherwise
it passes the forward to the rest of the Struts chain.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Result types for S1
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Antonio Petrelli wrote:
> 2007/12/13, Frank W. Zammetti <fz...@omnytex.com>:
>> if we simply say that if it DOESN'T begin with a slash,
>> then it means something else, be it a template or class, or something
>> else, how would you feel about that?
>
> It seems like Tiles definition names...
Are you saying there would be a conflict then? I admit I'm not at all
familiar with the internals of Tiles (or Tiles in general, at least not
the most recent versions), so I can't say.
> Antonio
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Result types for S1
Posted by Paul Benedict <pb...@apache.org>.
You might be totally right. Thanks for helping my brain along. In fact, the
new execute method should probably be for classes which do not extend
Action. Because everything is stuck in TLS, it's always accessible. For
regular POJO, use the new way.
Paul
On Dec 13, 2007 4:59 PM, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Paul Benedict wrote:
> > I said new method, I didn't say replace the previous method :-) I
> wouldn't
> > implement anything that didn't allow current Struts actions to work.
> It's
> > all blue sky thinking so there's a lot you can help me figure out.
>
> No, I knew you wouldn't do that... although it wasn't initially clear to
> me how it would still be compatible, I had no doubt that was just my
> lack of understanding and you had that answer :)
>
> So, let me think this through out loud, make sure I'm on the same page
> as you...
>
> I'm a Struts developer, and I upgrade to 1.4 where all this stuff
> presumably is. Ok, so none of my existing code breaks, good to go
> there. But, I want to use this new JSON capability, and let's think
> simplest case: I just want to render my ActionForm as JSON and return
> it, no options to fiddle with or anything like that.
>
> So, I need to implement this new version of execute(). Not too big a
> deal. I'm OK with it so far. But what if I want to take an existing
> Action and do this? Still not a big deal I think: implement the new
> version of execute(), call the existing execute(), ignore the returned
> ActionForward and do whatever I need to do to get the JSON output to
> happen. Not a big deal.
>
> I don't care about the ThreadLocal stuff, or the alternate execute()
> version, unless I want to.
>
> The only objection that comes to mind for me is that maybe having two
> different types of execute() methods is a bit more confusing than it
> needs to be. I don't think it's the kind of thing you can deprecate
> over time, there's too big an installed base to do that with.
>
> My puny brain needs simplicity :) So, I'm wondering if there's not a
> simpler answer, which is my roundabout way of asking: what do you think
> of my suggested approach to this? Just to recap:
>
> >> Another way to do it might be to subclass ActionForward, calling it
> >> Result. Then, after the Action executes, we try to cast the result to
> >> Result, and if we catch a ClassCastException, then we have a plain old
> >> ActionForward and we process it same as always, but if the exception
> >> didn't occur then we have a Result and we can go off and do "result
> >> things(tm)".
>
> Because to me, while what you propose isn't exactly rocket science to
> implement or make use of, I think this approach is simpler still, and
> requires very minimal changes to the codebase, also something I strive
> for (not just with Struts either)
>
> ...or did you have some other motivation for those changes besides this?
> Did you have other plans that hinge on these changes?
>
> Frank
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM/Yahoo: fzammetti
> MSN: fzammetti@hotmail.com
> Author of "Practical Ajax Projects With Java Technology"
> (2006, Apress, ISBN 1-59059-695-1)
> and "JavaScript, DOM Scripting and Ajax Projects"
> (2007, Apress, ISBN 1-59059-816-4)
> Java Web Parts - http://javawebparts.sourceforge.net
> Supplying the wheel, so you don't have to reinvent it!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Result types for S1
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Frank W. Zammetti wrote:
> >> Another way to do it might be to subclass ActionForward, calling it
> >> Result. Then, after the Action executes, we try to cast the result to
> >> Result, and if we catch a ClassCastException, then we have a plain old
> >> ActionForward and we process it same as always, but if the exception
> >> didn't occur then we have a Result and we can go off and do "result
> >> things(tm)".
Just to change that slightly and clarify it with an example, we'd wind
up with this:
class Result extends ActionForward {
// Might not be anything here, just a marker in essence
}
class JSONResult extends Result {
// Do JSON generation, whatever that means
}
...then in the Action...
public ActionForward execute(ActionMapping mapping, ActionForm inForm,
HttpServletRequest request, HttpServletResponse response) throws
Exception {
return JSONResult(inForm);
}
...then, in the RP chain, somewhere after the Action execution...
// af is the ActionForward returned by execute()
Result r = null;
try {
r = (Result)af;
processResult(r);
} catch (ClassCastException cce) {
processActionForward(r);
}
I have no doubt I'm screwing up something simple here, since that's my
MO, but if not, that's what I'm describing.
(I just saw your response by the way, so I'm anxious to see what you
think of this, since it's more fleshed out and concrete)
Frank
> Because to me, while what you propose isn't exactly rocket science to
> implement or make use of, I think this approach is simpler still, and
> requires very minimal changes to the codebase, also something I strive
> for (not just with Struts either)
>
> ...or did you have some other motivation for those changes besides this?
> Did you have other plans that hinge on these changes?
>
> Frank
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM/Yahoo: fzammetti
> MSN: fzammetti@hotmail.com
> Author of "Practical Ajax Projects With Java Technology"
> (2006, Apress, ISBN 1-59059-695-1)
> and "JavaScript, DOM Scripting and Ajax Projects"
> (2007, Apress, ISBN 1-59059-816-4)
> Java Web Parts - http://javawebparts.sourceforge.net
> Supplying the wheel, so you don't have to reinvent it!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
--
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Result types for S1
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Paul Benedict wrote:
> I said new method, I didn't say replace the previous method :-) I wouldn't
> implement anything that didn't allow current Struts actions to work. It's
> all blue sky thinking so there's a lot you can help me figure out.
No, I knew you wouldn't do that... although it wasn't initially clear to
me how it would still be compatible, I had no doubt that was just my
lack of understanding and you had that answer :)
So, let me think this through out loud, make sure I'm on the same page
as you...
I'm a Struts developer, and I upgrade to 1.4 where all this stuff
presumably is. Ok, so none of my existing code breaks, good to go
there. But, I want to use this new JSON capability, and let's think
simplest case: I just want to render my ActionForm as JSON and return
it, no options to fiddle with or anything like that.
So, I need to implement this new version of execute(). Not too big a
deal. I'm OK with it so far. But what if I want to take an existing
Action and do this? Still not a big deal I think: implement the new
version of execute(), call the existing execute(), ignore the returned
ActionForward and do whatever I need to do to get the JSON output to
happen. Not a big deal.
I don't care about the ThreadLocal stuff, or the alternate execute()
version, unless I want to.
The only objection that comes to mind for me is that maybe having two
different types of execute() methods is a bit more confusing than it
needs to be. I don't think it's the kind of thing you can deprecate
over time, there's too big an installed base to do that with.
My puny brain needs simplicity :) So, I'm wondering if there's not a
simpler answer, which is my roundabout way of asking: what do you think
of my suggested approach to this? Just to recap:
>> Another way to do it might be to subclass ActionForward, calling it
>> Result. Then, after the Action executes, we try to cast the result to
>> Result, and if we catch a ClassCastException, then we have a plain old
>> ActionForward and we process it same as always, but if the exception
>> didn't occur then we have a Result and we can go off and do "result
>> things(tm)".
Because to me, while what you propose isn't exactly rocket science to
implement or make use of, I think this approach is simpler still, and
requires very minimal changes to the codebase, also something I strive
for (not just with Struts either)
...or did you have some other motivation for those changes besides this?
Did you have other plans that hinge on these changes?
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Result types for S1
Posted by Paul Benedict <pb...@apache.org>.
I said new method, I didn't say replace the previous method :-) I wouldn't
implement anything that didn't allow current Struts actions to work. It's
all blue sky thinking so there's a lot you can help me figure out.
On Dec 13, 2007 3:01 PM, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Paul Benedict wrote:
> > I am all for it. I was thinking the framework needs these additional
> > enhancements to support it though:
> >
> > * A new Command to expose the ActionContext as a ThreadLocal variable
> > * New execute() method could then contain no parameters
> > * Allow returning void (equal to null), String (result/forward name), or
> > ActionForward
>
> How do you then propose to keep backwards-compatibility? How would
> existing Actions continue to work without change?
>
> Another way to do it might be to subclass ActionForward, calling it
> Result. Then, after the Action executes, we try to cast the result to
> Result, and if we catch a ClassCastException, then we have a plain old
> ActionForward and we process it same as always, but if the exception
> didn't occur then we have a Result and we can go off and do "result
> things(tm)".
>
> This has the benefit of zero impact on existing application code, and
> isn't in any way a big change. You might argue it's a little ugly
> internally, and I'd agree to some extent!, but I don't see it as being
> too bad. I like the lesser degree of change myself.
>
> > Paul
>
> Frank
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM/Yahoo: fzammetti
> MSN: fzammetti@hotmail.com
> Author of "Practical Ajax Projects With Java Technology"
> (2006, Apress, ISBN 1-59059-695-1)
> and "JavaScript, DOM Scripting and Ajax Projects"
> (2007, Apress, ISBN 1-59059-816-4)
> Java Web Parts - http://javawebparts.sourceforge.net
> Supplying the wheel, so you don't have to reinvent it!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Result types for S1
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Paul Benedict wrote:
> I am all for it. I was thinking the framework needs these additional
> enhancements to support it though:
>
> * A new Command to expose the ActionContext as a ThreadLocal variable
> * New execute() method could then contain no parameters
> * Allow returning void (equal to null), String (result/forward name), or
> ActionForward
How do you then propose to keep backwards-compatibility? How would
existing Actions continue to work without change?
Another way to do it might be to subclass ActionForward, calling it
Result. Then, after the Action executes, we try to cast the result to
Result, and if we catch a ClassCastException, then we have a plain old
ActionForward and we process it same as always, but if the exception
didn't occur then we have a Result and we can go off and do "result
things(tm)".
This has the benefit of zero impact on existing application code, and
isn't in any way a big change. You might argue it's a little ugly
internally, and I'd agree to some extent!, but I don't see it as being
too bad. I like the lesser degree of change myself.
> Paul
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Result types for S1
Posted by Paul Benedict <pb...@apache.org>.
I am all for it. I was thinking the framework needs these additional
enhancements to support it though:
* A new Command to expose the ActionContext as a ThreadLocal variable
* New execute() method could then contain no parameters
* Allow returning void (equal to null), String (result/forward name), or
ActionForward
Paul
On Dec 13, 2007 2:17 PM, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Paul Benedict wrote:
> > I find it more palatable to introduce the <result> tag with a type,
> Frank
> > and Atonio. Yes, I would agree that a <forward> is a shorthand for a
> <result
> > type="forward">. I definitely do not want to build a Struts 2
> look-a-like,
> > but it does make sense for a back port for some of its good idea.
>
> Well, I wouldn't be at all against that approach either... I didn't
> suggest anything like that initially because in the past there's always
> been resistance to changes to the DTD, which this would require. If now
> though there's consensus that says that's the approach we'd like to
> take, I'm all for it and will happily go off and implement it.
>
> > Paul
>
> Frank
>
> > On Dec 13, 2007 2:00 PM, Antonio Petrelli <an...@gmail.com>
> > wrote:
> >
> >> 2007/12/13, Frank W. Zammetti <fz...@omnytex.com>:
> >>> if we simply say that if it DOESN'T begin with a slash,
> >>> then it means something else, be it a template or class, or something
> >>> else, how would you feel about that?
> >> It seems like Tiles definition names...
> >>
> >> Antonio
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
> >
> > ------------------------------------------------------------------------
> >
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.503 / Virus Database: 269.17.1/1182 - Release Date:
> 12/12/2007 11:29 AM
>
> --
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM/Yahoo: fzammetti
> MSN: fzammetti@hotmail.com
> Author of "Practical Ajax Projects With Java Technology"
> (2006, Apress, ISBN 1-59059-695-1)
> and "JavaScript, DOM Scripting and Ajax Projects"
> (2007, Apress, ISBN 1-59059-816-4)
> Java Web Parts - http://javawebparts.sourceforge.net
> Supplying the wheel, so you don't have to reinvent it!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Result types for S1
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Paul Benedict wrote:
> I find it more palatable to introduce the <result> tag with a type, Frank
> and Atonio. Yes, I would agree that a <forward> is a shorthand for a <result
> type="forward">. I definitely do not want to build a Struts 2 look-a-like,
> but it does make sense for a back port for some of its good idea.
Well, I wouldn't be at all against that approach either... I didn't
suggest anything like that initially because in the past there's always
been resistance to changes to the DTD, which this would require. If now
though there's consensus that says that's the approach we'd like to
take, I'm all for it and will happily go off and implement it.
> Paul
Frank
> On Dec 13, 2007 2:00 PM, Antonio Petrelli <an...@gmail.com>
> wrote:
>
>> 2007/12/13, Frank W. Zammetti <fz...@omnytex.com>:
>>> if we simply say that if it DOESN'T begin with a slash,
>>> then it means something else, be it a template or class, or something
>>> else, how would you feel about that?
>> It seems like Tiles definition names...
>>
>> Antonio
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.503 / Virus Database: 269.17.1/1182 - Release Date: 12/12/2007 11:29 AM
--
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Result types for S1
Posted by Paul Benedict <pb...@apache.org>.
I find it more palatable to introduce the <result> tag with a type, Frank
and Atonio. Yes, I would agree that a <forward> is a shorthand for a <result
type="forward">. I definitely do not want to build a Struts 2 look-a-like,
but it does make sense for a back port for some of its good idea.
Paul
On Dec 13, 2007 2:00 PM, Antonio Petrelli <an...@gmail.com>
wrote:
> 2007/12/13, Frank W. Zammetti <fz...@omnytex.com>:
> > if we simply say that if it DOESN'T begin with a slash,
> > then it means something else, be it a template or class, or something
> > else, how would you feel about that?
>
> It seems like Tiles definition names...
>
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Result types for S1
Posted by Antonio Petrelli <an...@gmail.com>.
2007/12/13, Frank W. Zammetti <fz...@omnytex.com>:
> if we simply say that if it DOESN'T begin with a slash,
> then it means something else, be it a template or class, or something
> else, how would you feel about that?
It seems like Tiles definition names...
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Result types for S1
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
What do you think of the idea of a <forward> being able to map to a
Freemarker template, or maybe even a class? I wouldn't view this as
repurposing it myself because the destination of a forward is someting
that renders a response... Typically it maps to a URI that is forwarded
or redirected to, but both of those assume the path attribute begins
with a / ... if we simply say that if it DOESN'T begin with a slash,
then it means something else, be it a template or class, or something
else, how would you feel about that? (ignore the specifics of what it
would actually mean or how it would work, just think about it conceptually)
Frank
Paul Benedict wrote:
> I don't think it's a good idea to repurpose the <forward> attribute. It's
> not identical to <result> in s2 with a type. I would truly recommend a
> different kind of tag here.
>
> Paul
>
> On Dec 13, 2007 12:43 PM, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
>> Laurie Harper wrote:
>>> Or stick with mapping.findForward(something) but provide a mechanism for
>>> mapping that result type to the appropriate (JSON/XML/etc) rederer in
>>> struts-config.xml. That would eliminate any concern over clashes with
>>> existing action return strings (small though the risk is), and would be
>>> consistent with existing declarative semantics.
>>>
>>> With that, it could be easy to make the 'result providers' such as JSON
>>> serialization, XML serialization and so forth plugable/configurable
>>> and/or parameterizable.
>>>
>>> For example:
>>>
>>> <action name="/orders" ...>
>>> <forward type="json" name="json-brief"/>
>>> <forward type="json" name="json-brief">
>>> <!-- JSON serializer parameters go here -->
>>> </forward>
>>> ...
>> I was thinking along those lines too, especially in terms of
>> parameterization... but, I think Antonio still has a valid point in
>> terms of findForward() meaning one thing, and doing it this way in a
>> sense "overloads" that meaning, which arguably isn't as nice.
>>
>> I re-implemented it now by adding a renderResult() method to
>> ActionForward, and that works nicely. That code I think is fairly good
>> now, could create a patch for it. But...
>>
>> There's two concerns left... one is parameterization. First, let me
>> show you where I am right now:
>>
>> return mapping.renderResult("json", response, inForm);
>>
>> I think that addresses Antonio's concern. Now, for paramerization, I'm
>> thinking simply using the <set-property> on the Action might be fine...
>> then, this call would become:
>>
>> return mapping.renderResult("json", response, inForm, this);
>>
>> Each renderer could look for specific attribute of the Action to
>> configure it.
>>
>> Also, I just saw Martin's note, and the point about not always using the
>> ActionForm is a good one, so one of the things the renderers could look
>> for is an attribute, maybe call it simply "beanToRender". That way, if
>> the Action wants to return another object as JSON, they just point that
>> attribute at the object and it's good to go. If that attribute is null,
>> or not present, the ActionForm is used.
>>
>> The second concern... well, the second concern I'll skip for now because
>> I want to go reply to Martin's reply specifically because it might
>> change all this anyway :)
>>
>>> L.
>> Frank
>>
>> --
>> Frank W. Zammetti
>> Founder and Chief Software Architect
>> Omnytex Technologies
>> http://www.omnytex.com
>> AIM/Yahoo: fzammetti
>> MSN: fzammetti@hotmail.com
>> Author of "Practical Ajax Projects With Java Technology"
>> (2006, Apress, ISBN 1-59059-695-1)
>> and "JavaScript, DOM Scripting and Ajax Projects"
>> (2007, Apress, ISBN 1-59059-816-4)
>> Java Web Parts - http://javawebparts.sourceforge.net
>> Supplying the wheel, so you don't have to reinvent it!
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.503 / Virus Database: 269.17.1/1182 - Release Date: 12/12/2007 11:29 AM
--
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Result types for S1
Posted by Paul Benedict <pb...@apache.org>.
I don't think it's a good idea to repurpose the <forward> attribute. It's
not identical to <result> in s2 with a type. I would truly recommend a
different kind of tag here.
Paul
On Dec 13, 2007 12:43 PM, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Laurie Harper wrote:
> > Or stick with mapping.findForward(something) but provide a mechanism for
> > mapping that result type to the appropriate (JSON/XML/etc) rederer in
> > struts-config.xml. That would eliminate any concern over clashes with
> > existing action return strings (small though the risk is), and would be
> > consistent with existing declarative semantics.
> >
> > With that, it could be easy to make the 'result providers' such as JSON
> > serialization, XML serialization and so forth plugable/configurable
> > and/or parameterizable.
> >
> > For example:
> >
> > <action name="/orders" ...>
> > <forward type="json" name="json-brief"/>
> > <forward type="json" name="json-brief">
> > <!-- JSON serializer parameters go here -->
> > </forward>
> > ...
>
> I was thinking along those lines too, especially in terms of
> parameterization... but, I think Antonio still has a valid point in
> terms of findForward() meaning one thing, and doing it this way in a
> sense "overloads" that meaning, which arguably isn't as nice.
>
> I re-implemented it now by adding a renderResult() method to
> ActionForward, and that works nicely. That code I think is fairly good
> now, could create a patch for it. But...
>
> There's two concerns left... one is parameterization. First, let me
> show you where I am right now:
>
> return mapping.renderResult("json", response, inForm);
>
> I think that addresses Antonio's concern. Now, for paramerization, I'm
> thinking simply using the <set-property> on the Action might be fine...
> then, this call would become:
>
> return mapping.renderResult("json", response, inForm, this);
>
> Each renderer could look for specific attribute of the Action to
> configure it.
>
> Also, I just saw Martin's note, and the point about not always using the
> ActionForm is a good one, so one of the things the renderers could look
> for is an attribute, maybe call it simply "beanToRender". That way, if
> the Action wants to return another object as JSON, they just point that
> attribute at the object and it's good to go. If that attribute is null,
> or not present, the ActionForm is used.
>
> The second concern... well, the second concern I'll skip for now because
> I want to go reply to Martin's reply specifically because it might
> change all this anyway :)
>
> > L.
>
> Frank
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM/Yahoo: fzammetti
> MSN: fzammetti@hotmail.com
> Author of "Practical Ajax Projects With Java Technology"
> (2006, Apress, ISBN 1-59059-695-1)
> and "JavaScript, DOM Scripting and Ajax Projects"
> (2007, Apress, ISBN 1-59059-816-4)
> Java Web Parts - http://javawebparts.sourceforge.net
> Supplying the wheel, so you don't have to reinvent it!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Result types for S1
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Laurie Harper wrote:
> Or stick with mapping.findForward(something) but provide a mechanism for
> mapping that result type to the appropriate (JSON/XML/etc) rederer in
> struts-config.xml. That would eliminate any concern over clashes with
> existing action return strings (small though the risk is), and would be
> consistent with existing declarative semantics.
>
> With that, it could be easy to make the 'result providers' such as JSON
> serialization, XML serialization and so forth plugable/configurable
> and/or parameterizable.
>
> For example:
>
> <action name="/orders" ...>
> <forward type="json" name="json-brief"/>
> <forward type="json" name="json-brief">
> <!-- JSON serializer parameters go here -->
> </forward>
> ...
I was thinking along those lines too, especially in terms of
parameterization... but, I think Antonio still has a valid point in
terms of findForward() meaning one thing, and doing it this way in a
sense "overloads" that meaning, which arguably isn't as nice.
I re-implemented it now by adding a renderResult() method to
ActionForward, and that works nicely. That code I think is fairly good
now, could create a patch for it. But...
There's two concerns left... one is parameterization. First, let me
show you where I am right now:
return mapping.renderResult("json", response, inForm);
I think that addresses Antonio's concern. Now, for paramerization, I'm
thinking simply using the <set-property> on the Action might be fine...
then, this call would become:
return mapping.renderResult("json", response, inForm, this);
Each renderer could look for specific attribute of the Action to
configure it.
Also, I just saw Martin's note, and the point about not always using the
ActionForm is a good one, so one of the things the renderers could look
for is an attribute, maybe call it simply "beanToRender". That way, if
the Action wants to return another object as JSON, they just point that
attribute at the object and it's good to go. If that attribute is null,
or not present, the ActionForm is used.
The second concern... well, the second concern I'll skip for now because
I want to go reply to Martin's reply specifically because it might
change all this anyway :)
> L.
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Result types for S1
Posted by Laurie Harper <la...@holoweb.net>.
Frank W. Zammetti wrote:
> Hi Antonio,
> Antonio Petrelli wrote:
>> 2007/12/13, Frank W. Zammetti <fz...@omnytex.com>:
>>> return mapping.findForward("JSONResultType");
>>
>> I don't like this syntax, because it mixes the concept of forward (to a
>> page) with the rendering of the ActionForm. Probably a more specific
>> ActionMapping method, or different types of ActionForwards, could be
>> better.
>
> So you'd rather see something like:
>
> return mapping.renderResult("JSON");
Or stick with mapping.findForward(something) but provide a mechanism for
mapping that result type to the appropriate (JSON/XML/etc) rederer in
struts-config.xml. That would eliminate any concern over clashes with
existing action return strings (small though the risk is), and would be
consistent with existing declarative semantics.
With that, it could be easy to make the 'result providers' such as JSON
serialization, XML serialization and so forth plugable/configurable
and/or parameterizable.
For example:
<action name="/orders" ...>
<forward type="json" name="json-brief"/>
<forward type="json" name="json-brief">
<!-- JSON serializer parameters go here -->
</forward>
...
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Result types for S1
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Hi Antonio,
Antonio Petrelli wrote:
> 2007/12/13, Frank W. Zammetti <fz...@omnytex.com>:
>> return mapping.findForward("JSONResultType");
>
>
>
> I don't like this syntax, because it mixes the concept of forward (to a
> page) with the rendering of the ActionForm. Probably a more specific
> ActionMapping method, or different types of ActionForwards, could be better.
So you'd rather see something like:
return mapping.renderResult("JSON");
...or maybe doResult()?
If so, that's not bad at all... I like that better actually because then
I think I just need to modify ActionMapping, none of the chain Commands,
and so long as the class implementing the JSON rendering returns null,
then everything after the Action execution works just like always. It's
actually *less* intrusive in some ways, which was one of my goals.
> Antonio
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Result types for S1
Posted by Antonio Petrelli <an...@gmail.com>.
2007/12/13, Frank W. Zammetti <fz...@omnytex.com>:
>
> return mapping.findForward("JSONResultType");
I don't like this syntax, because it mixes the concept of forward (to a
page) with the rendering of the ActionForm. Probably a more specific
ActionMapping method, or different types of ActionForwards, could be better.
Antonio
Re: Result types for S1
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Martin Cooper wrote:
> And I'm trying to avoid hacks like "special" values (or "special" anythings)
> that only lead to trouble. People will end up (re)using the same names, not
> realising that they're already "taken" for something they may not even care
> about, the end result being debugging hell.
And I agree with that... that's why the last iteration of what I
suggested to Paul in this thread does away with these "special" values,
at least partly for the reason you state.
>> Second, that doesn't sound terribly efficient to me. Having to
>> essentially invoke a whole new request cycle, servlet invocation, all
>> the overhead that involves, sounds like a bad idea to me in terms of
>> performance and scalability.
>
>
> Huh? You're kidding, right? This is *exactly* the same, in terms of
> efficiency, as forwarding to a JSP or another Struts action. That's the
> point - it's *exactly* the same mechanism that every Struts developer has
> been using for years. If that's an unacceptable performance impact, we must
> have been screwed all along. ;-)
Ok, yeah, you got me on that one, I didn't think that through properly.
However, I believe my statement is still valid, just not for the reasons
I was originally thinking... certainly you would agree that executing a
class that is essentially part of the Struts RP chain is more efficient
(assuming it's not doing something inefficient!) than forwarding to
*any* resource, be it a servlet, JSP or what have you, wouldn't you? I
don't see how you could say otherwise. Now, I'd agree that depending on
what work is actually being done that the different may not be too
great, but I've gotta believe there'd be a difference regardless.
>> What's the point of using a framework like Struts in the first place if
>> it can't provide something (relatively) simple like this? That would be
>> my answer. I don't view returning a special forward, or better still, a
>> new subclass as I suggested to Paul, as more complicated, just the
>> opposite: I see it as clearly less so.
>
>
> You mean "can't provide something [...] like this" automagically, right?
> I've suggested a way that Struts can provide this very simply, and in a way
> that will not introduce *any* new concepts to the Struts developer. It's not
> automagical, but sheesh, S1 has never been automagical. I am not in favour
> of hacking around with it now just to make it so for some relatively minor
> enhancement.
If you view this as a minor enhancement, then that's the disconnect
here. If it is was *just* about JSON or XML, then yeah, that'd be
pretty minor and you might convince me. Again I go back to the last
iteration of what I'm suggesting, because frankly it's evolved as this
discussion has progressed. It opens up the door to much more than just
JSON, XML and relatively simple things like that. Think DataVision,
JReports, etc.
And yeah, I'm trying to make things automagical, you're right. Since
when is that not desirable? Isn't the whole point of a framework to
remove some work for the developer?
To put it another way: why WOULDN'T we want to make things like this
automagical if we can? Why WOULDN'T we want to add capabilities to
Struts that a developer gets for as close to free as possible?
>> Besides, I think the more the answer to things like this is "add this
>> piece that's not a part of Struts", the less point there is to Struts.
>
>
> At what point did I suggest adding something that wasn't part of Struts?
You suggested a servlet to render the JSON. That's not part of the
framework. And I bet you're going to point out that JSPs then would be
the same thing because after all, they're servlets in the end. The
point I'm making though is that what you're suggesting is something
additional the developer has to remember to configure, some other
component they have to bring into their project (because I presume you
wouldn't want such renderer servlets included in the Struts JAR, correct?)
And I'm asking, what's the deciding factor as to whether something
belongs in the framework or not? Many other frameworks provide this
type of thing, S2 as one big example, so why should the answer be
different for S1? You're not suggesting results in S2 should be
replaced with servlets that are forwarded to, are you?
> Martin Cooper
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Result types for S1
Posted by Martin Cooper <ma...@apache.org>.
On Dec 13, 2007 9:14 PM, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Martin Cooper wrote:
> > Given the following paragraphs, I think we might be on different
> planets.
> > ;-)
>
> Could be... some would say I rent a summer home on some distant world :)
>
> > I don't see that you need Freemarker or anything like it, nor do I see
> any
> > reason you couldn't continue to use the json-lib package you're already
> > using. Why not simply add a rendering servlet that does the work of
> picking
> > up the appropriate bean and rendering it by calling into the library,
> > sending the output to the servlet output stream? If you do that, you
> need
> > *no* other changes to Struts. Anyone who wants to use it simply adds the
> > rendering servlet to their web.xml, adds a global forward (or more than
> one,
> > if we want to parameterise things) that forwards to the servlet, and
> then
> > uses that as the target of their actions. Done.
>
> I wouldn't like this for two reasons... first, it's something additional
> the developer has to do on top of Struts. I'm trying to avoid that.
And I'm trying to avoid hacks like "special" values (or "special" anythings)
that only lead to trouble. People will end up (re)using the same names, not
realising that they're already "taken" for something they may not even care
about, the end result being debugging hell.
> Second, that doesn't sound terribly efficient to me. Having to
> essentially invoke a whole new request cycle, servlet invocation, all
> the overhead that involves, sounds like a bad idea to me in terms of
> performance and scalability.
Huh? You're kidding, right? This is *exactly* the same, in terms of
efficiency, as forwarding to a JSP or another Struts action. That's the
point - it's *exactly* the same mechanism that every Struts developer has
been using for years. If that's an unacceptable performance impact, we must
have been screwed all along. ;-)
(Although, I think you're right WRT Freemarker... as the idea has
> evolved from discussion with Paul here, I tend to agree with you on that
> at this point. Freemarker could well be another result type, just like
> in S2, but it shouldn't be necessary for the JSON or XML result)
>
> > Why do we need anything more complicated than that?
>
> What's the point of using a framework like Struts in the first place if
> it can't provide something (relatively) simple like this? That would be
> my answer. I don't view returning a special forward, or better still, a
> new subclass as I suggested to Paul, as more complicated, just the
> opposite: I see it as clearly less so.
You mean "can't provide something [...] like this" automagically, right?
I've suggested a way that Struts can provide this very simply, and in a way
that will not introduce *any* new concepts to the Struts developer. It's not
automagical, but sheesh, S1 has never been automagical. I am not in favour
of hacking around with it now just to make it so for some relatively minor
enhancement.
> Besides, I think the more the answer to things like this is "add this
> piece that's not a part of Struts", the less point there is to Struts.
At what point did I suggest adding something that wasn't part of Struts?
--
Martin Cooper
I mean, after all, shouldn't we then have told Musachy that the JSON
> plugin should be a filter, servlet, or something like that? I haven't
> seen a single person say that, and rightly so. I don't see it being any
> different, except that S2 has a plug-in mechanism for things like
> that... but at the end of the day it's still a part of the framework, if
> only a loosely-coupled one, not an external piece that I as an
> application developer then have to manage.
>
> > Martin Cooper
>
> Frank
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM/Yahoo: fzammetti
> MSN: fzammetti@hotmail.com
> Author of "Practical Ajax Projects With Java Technology"
> (2006, Apress, ISBN 1-59059-695-1)
> and "JavaScript, DOM Scripting and Ajax Projects"
> (2007, Apress, ISBN 1-59059-816-4)
> Java Web Parts - http://javawebparts.sourceforge.net
> Supplying the wheel, so you don't have to reinvent it!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Result types for S1
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Martin Cooper wrote:
> Given the following paragraphs, I think we might be on different planets.
> ;-)
Could be... some would say I rent a summer home on some distant world :)
> I don't see that you need Freemarker or anything like it, nor do I see any
> reason you couldn't continue to use the json-lib package you're already
> using. Why not simply add a rendering servlet that does the work of picking
> up the appropriate bean and rendering it by calling into the library,
> sending the output to the servlet output stream? If you do that, you need
> *no* other changes to Struts. Anyone who wants to use it simply adds the
> rendering servlet to their web.xml, adds a global forward (or more than one,
> if we want to parameterise things) that forwards to the servlet, and then
> uses that as the target of their actions. Done.
I wouldn't like this for two reasons... first, it's something additional
the developer has to do on top of Struts. I'm trying to avoid that.
Second, that doesn't sound terribly efficient to me. Having to
essentially invoke a whole new request cycle, servlet invocation, all
the overhead that involves, sounds like a bad idea to me in terms of
performance and scalability.
(Although, I think you're right WRT Freemarker... as the idea has
evolved from discussion with Paul here, I tend to agree with you on that
at this point. Freemarker could well be another result type, just like
in S2, but it shouldn't be necessary for the JSON or XML result)
> Why do we need anything more complicated than that?
What's the point of using a framework like Struts in the first place if
it can't provide something (relatively) simple like this? That would be
my answer. I don't view returning a special forward, or better still, a
new subclass as I suggested to Paul, as more complicated, just the
opposite: I see it as clearly less so.
Besides, I think the more the answer to things like this is "add this
piece that's not a part of Struts", the less point there is to Struts.
I mean, after all, shouldn't we then have told Musachy that the JSON
plugin should be a filter, servlet, or something like that? I haven't
seen a single person say that, and rightly so. I don't see it being any
different, except that S2 has a plug-in mechanism for things like
that... but at the end of the day it's still a part of the framework, if
only a loosely-coupled one, not an external piece that I as an
application developer then have to manage.
> Martin Cooper
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Result types for S1
Posted by Martin Cooper <ma...@apache.org>.
On Dec 13, 2007 10:59 AM, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Martin Cooper wrote:
> > 1) We simply provide servlets / other entry points that can accomplish
> the
> > rendering to JSON / XML / whatever. The developer can then configure
> those
> > as global forwards and use them as any other forward. This makes the
> process
> > identical to what developers do now, but gives them the additional
> rendering
> > capabilities.
>
> This was interestingly exactly what I was thinking originally :)
Given the following paragraphs, I think we might be on different planets.
;-)
I don't see that you need Freemarker or anything like it, nor do I see any
reason you couldn't continue to use the json-lib package you're already
using. Why not simply add a rendering servlet that does the work of picking
up the appropriate bean and rendering it by calling into the library,
sending the output to the servlet output stream? If you do that, you need
*no* other changes to Struts. Anyone who wants to use it simply adds the
rendering servlet to their web.xml, adds a global forward (or more than one,
if we want to parameterise things) that forwards to the servlet, and then
uses that as the target of their actions. Done.
Why do we need anything more complicated than that?
--
Martin Cooper
>
> I was thinking about introducing Freemarker into the mix... then, when
> Struts started up, it would insert some "automatic" global forwards,
> "json", "xml" for example. Then a Freemarker template is used to render
> the output. But, I'm not sure how well Freemarker will truly do JSON or
> XML in a generic way, whereas the json-lib I've been using so far is
> very simple (I believe it can do XML from JSON too, so we can get XML
> from it as well, although maybe not as efficiently as possible).
>
> But, that means we'd still essentially have "special" values though
> because somewhere in the processing chain it would have to recognize
> that the forward name specified maps to a Freemarker template. But,
> it's a special value within the same overall architecture, so I think it
> would be OK.
>
> I'm also not sure what the most elegant way to detect a Freemarker-based
> forward would be... maybe it's simply if the path doesn't begin with /
> then we assume it's a classpath specification, i.e, something like
> "org.apache.struts.results.JSONResult.ftl".
>
> I think doing it this way would also mean that a developer could add a
> new result type easily because it's just a new global forward entry,
> with a path pointing to the Freemarker template, and so long as its in
> the classpath we're good to go.
>
>
> > 2) We not limit this to rendering the action form. Rendering the form
> might
> > be desirable in some situations, but in many others, it would be some
> other
> > bean that should be rendered, not the form bean. We could define an
> > attribute under which the bean is stored, and the renderers could look
> for
> > that and perhaps fall back to the form bean if it isn't there.
>
> Yeah, that's a good point... maybe the best way to do that is with some
> <set-property> elements defined at the action level... that would also
> address Laurie's point about parameterization. Shouldn't be a big deal
> to make the ActionContext available to the Freemarker template, so it
> then has access to the Action, ActionForm, whatever else, and we could
> look for setting on the action (I think that's the right place).
>
> It's a different approach than what I've been discussing so far in some
> important ways though, so what does everyone think of it? I can
> probably get it at least working by late tonight and can throw it up
> somewhere for everyone to look at, I don't think it's much of a leap
> really effort-wise.
>
> > --
> > Martin Cooper
>
> Frank
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM/Yahoo: fzammetti
> MSN: fzammetti@hotmail.com
> Author of "Practical Ajax Projects With Java Technology"
> (2006, Apress, ISBN 1-59059-695-1)
> and "JavaScript, DOM Scripting and Ajax Projects"
> (2007, Apress, ISBN 1-59059-816-4)
> Java Web Parts - http://javawebparts.sourceforge.net
> Supplying the wheel, so you don't have to reinvent it!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Result types for S1
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Martin Cooper wrote:
> 1) We simply provide servlets / other entry points that can accomplish the
> rendering to JSON / XML / whatever. The developer can then configure those
> as global forwards and use them as any other forward. This makes the process
> identical to what developers do now, but gives them the additional rendering
> capabilities.
This was interestingly exactly what I was thinking originally :)
I was thinking about introducing Freemarker into the mix... then, when
Struts started up, it would insert some "automatic" global forwards,
"json", "xml" for example. Then a Freemarker template is used to render
the output. But, I'm not sure how well Freemarker will truly do JSON or
XML in a generic way, whereas the json-lib I've been using so far is
very simple (I believe it can do XML from JSON too, so we can get XML
from it as well, although maybe not as efficiently as possible).
But, that means we'd still essentially have "special" values though
because somewhere in the processing chain it would have to recognize
that the forward name specified maps to a Freemarker template. But,
it's a special value within the same overall architecture, so I think it
would be OK.
I'm also not sure what the most elegant way to detect a Freemarker-based
forward would be... maybe it's simply if the path doesn't begin with /
then we assume it's a classpath specification, i.e, something like
"org.apache.struts.results.JSONResult.ftl".
I think doing it this way would also mean that a developer could add a
new result type easily because it's just a new global forward entry,
with a path pointing to the Freemarker template, and so long as its in
the classpath we're good to go.
> 2) We not limit this to rendering the action form. Rendering the form might
> be desirable in some situations, but in many others, it would be some other
> bean that should be rendered, not the form bean. We could define an
> attribute under which the bean is stored, and the renderers could look for
> that and perhaps fall back to the form bean if it isn't there.
Yeah, that's a good point... maybe the best way to do that is with some
<set-property> elements defined at the action level... that would also
address Laurie's point about parameterization. Shouldn't be a big deal
to make the ActionContext available to the Freemarker template, so it
then has access to the Action, ActionForm, whatever else, and we could
look for setting on the action (I think that's the right place).
It's a different approach than what I've been discussing so far in some
important ways though, so what does everyone think of it? I can
probably get it at least working by late tonight and can throw it up
somewhere for everyone to look at, I don't think it's much of a leap
really effort-wise.
> --
> Martin Cooper
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Result types for S1
Posted by Martin Cooper <ma...@apache.org>.
On Dec 12, 2007 10:12 PM, Frank W. Zammetti <fz...@omnytex.com> wrote:
> So, now that I've gotten my build problems sorted out, I was able to
> make some quick progress on what I wanted to work on, enough that I want
> to run this by everyone before I spit, polish and submit patches.
>
> Ted and I were discussing some ideas at The Ajax Experience back in
> October, specifically on how we could make S1 a little more
> AJAX-friendly and useful to developers doing RIA development. One of
> the ideas I had was the ability to have, essentially, "result types" in
> S1, ala S2.
>
> As a concrete example, say I have an Action that does this at the end:
>
> return mapping.findForward("JSONResultType");
>
> That mapping name would be a value specially recognized by Struts. The
> result of doing that would be that the response is a JSON representation
> of the appropriate ActionForm. One can easily imagine an XMLResultType,
> a FreemarkerResultType, a DataVisionResultType, and so on.
I like the idea, but not this particular approach. I especially don't like
the "special values" aspect to it. I'd prefer something like:
1) We simply provide servlets / other entry points that can accomplish the
rendering to JSON / XML / whatever. The developer can then configure those
as global forwards and use them as any other forward. This makes the process
identical to what developers do now, but gives them the additional rendering
capabilities.
2) We not limit this to rendering the action form. Rendering the form might
be desirable in some situations, but in many others, it would be some other
bean that should be rendered, not the form bean. We could define an
attribute under which the bean is stored, and the renderers could look for
that and perhaps fall back to the form bean if it isn't there.
--
Martin Cooper
>
> Note that the developer *does not* need to add any configuration to
> struts-config, they have only to specify that forward name, and the
> ActionForm to JSON conversion is automatic.
>
> I have this JSONResultType working right now, and it turns out it's a
> minimally intrusive change to the S1 code base overall, consisting of:
>
> * Some frankly minor changes to two Chain Commands
>
> * The addition of a new package containing one new class (the class that
> actually generates the result output, more to follow as new result types
> are implemented)
>
> * Some new dependencies: one during build (json-lib), and four at
> runtime (if using that result type): Commons Collections, Commons Lang,
> JSON-Lib and EZMorph).
>
> To be clear, this code isn't complete and ready immediately, it's POC
> grade right now, but it's not too far off either, maybe an hour or two
> worth of polishing.
>
> So, does anyone else think this is a worthwhile exercise? I certainly
> think it is: the ability to have automatic conversion of an ActionForm
> to JSON, XML, or whatever else, means S1 can become a true service
> provider for AJAX-based clients with no real effort on the developers'
> parts. It's not a huge change to the Struts code base, doesn't break
> compatibility in any way (I suppose unless someone happens to have the
> exact forward names I'm proposing here in their app already), and aside
> from the added dependencies, I don't see a down-side.
>
> Thoughts?
>
> Frank
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM/Yahoo: fzammetti
> MSN: fzammetti@hotmail.com
> Author of "Practical Ajax Projects With Java Technology"
> (2006, Apress, ISBN 1-59059-695-1)
> and "JavaScript, DOM Scripting and Ajax Projects"
> (2007, Apress, ISBN 1-59059-816-4)
> Java Web Parts - http://javawebparts.sourceforge.net
> Supplying the wheel, so you don't have to reinvent it!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>