On 6/28/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:
Michael Jouravlev wrote:
Do you mean by building DispatchCommand or DialogCommand? And then
slapping this command onto the chain... but I can replace Action as
well. Oh I see, Action is not an interface, but Command is. Always
keep
Paul, thanks for the warm support, I really appreciate it! Well, I
cannot thank you more, my ears are all red :-)
In any case, I think we can wait until 1.3.5 goes GA before making a
final decision about where this code belongs. In the meantime I will
continue working on it.
Integrating html2
Michael Jouravlev wrote:
In relation to html2, I am curious about how important client-side
validator is. I mean, comparing Ajax roundrip to amount of Javascript
preloaded for client-side validation, does it really make sense? And
if a form is filled out correctly, this validator code is not
On 6/28/06, Michael Jouravlev [EMAIL PROTECTED] wrote:
Integrating html2 would be nice too. It uses Ajax as well, so the two
engines can be combined into one.
In relation to html2, I am curious about how important client-side
validator is. I mean, comparing Ajax roundrip to amount of
I like the functionality that this provides. If I ever get to work on
another Struts 1 project, I would certainly like to use this. That
said, I'm -0 to integrating it, but I won't stand in the way if other
committers accept it. I think though that it works well enough
without being integrated
I'm on the same page as Hubert, as an outsider... I totally see this as
being a worthy extras, and probably something a lot of people would
use, but integrated into the core, it just doesn't feel right to me.
Frank
Hubert Rabago wrote:
I like the functionality that this provides. If I ever
I haven't read Michaels latest write up, so I don't know if its
substantially different, but last time I looked the only reason for
integrating the dispatch style into Action was (IMO) to encourage
its use. If thats still true then my opinion is unchanged:
On 6/28/06, Niall Pemberton [EMAIL PROTECTED] wrote:
I haven't read Michaels latest write up, so I don't know if its
substantially different, but last time I looked the only reason for
integrating the dispatch style into Action was (IMO) to encourage
its use.
If thats still true then my opinion
Niall's response has softened my position on the built-in action dispatching.
In my own projects, I went ahead and created a common BaseAction which all my
other actions extend from. The BaseAction uses EventDispatcherAction with a
pre-written execute method for the dispatching; subclasses just
Michael Jouravlev wrote:
Command is only better because it does not throw HTTP stuff right in
one's face.
Precisely the point :)
Is it really better? Maybe just for testing.
Not just for testing... wouldn't it be great if you could take that same
controller code, the code that really
On 6/28/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:
Michael Jouravlev wrote:
From webapp
point of view, Command is as bad as Action. Meaning that HttpServlet
has doGet() and doPost() and therefore forces people to think what
kind of request they are processing and what method is better to
Michael Jouravlev wrote:
If this not caring about any of that is anything like ASP.NET
coding, that this is not exactly true. Like, in ASP.NET there is a
well-defined lifecycle. But if you (well, me) wants to get rid of
POSTDATA situation, you need to call Response.redirect explicitly from
event
Interesting...I can see you have put a lot of time and thought into
this. My first pass seems to find this a cross between the portlet api
and JSF. What I saw missing from the articles and wiki pages is a
higher level justification:
- Why not just use portlets?
- Why not just use JSF?
-
Don, thanks for replying. See inline.
On 6/25/06, Don Brown [EMAIL PROTECTED] wrote:
Interesting...I can see you have put a lot of time and thought into
this. My first pass seems to find this a cross between the portlet api
and JSF. What I saw missing from the articles and wiki pages is a
Please disregard reference [1] as obsolete.
On 6/25/06, Michael Jouravlev [EMAIL PROTECTED] wrote:
skipped
[1] http://today.java.net/pub/a/today/2005/08/04/jspcomponents.html
[2] http://today.java.net/pub/a/today/2006/05/04/almost-portlets.html
[3] http://www.jspcontrols.net/
[4]
Ok, I see your points of leveraging known code and frameworks, but according to
your last article, what you developed isn't tied to Struts at all and can be
used with pure JSP. If that is the case, perhaps it would be better for this
component framework to have its own project and be treated
I want to stress out that what I suggest is not a framework ;) I did
try to make the standalone library independent of Struts for various
reasons. Still, its concept is quite foriegn to a Struts user, in
comparison to the principle of having code in Action and view in JSP.
Integrating this idea
I am +1 for Michael's idea.
I empathize with anyone who believe it's a non-standard way of doing portlets,
or that the idea is better as an independent plug-in, but consider that Struts
does not have to be the bare-of-the-bare of frameworks. Struts 1.x is
definitely legacy and has provided a
As most of you probably know, I have been quite obsessed with page
components developed with JSP or with JSP/Struts [1],[2]. My first
attempt used Struts/JSP, the second one is pure JSP-based [3]. It
proved to be quite robust, simple and it works. So now in my newly
acquired powers of Struts
19 matches
Mail list logo
