Michael Jouravlev wrote the following on 7/7/2005 5:13 PM:
So, tokens better than nothing, like Yugo comparing to bike. But it is
still a Yugo. (I am not selling Lexus here, merely a Corolla).
Yes, it does sound like your approach to the whole 'back' issue problem
handles things in a much nicer fashion. I'll definitely have to look at
least how you handle it. (I might not buy the whole Corolla but would
like those fancy rims:)
Rick, I am sorry, but you don't see it (yet). It would be a generic
action if it had not have two-phase request processing. I have a
SelectAction for what you think it is, just an improved
DispatchAction. But DialogAction is much more that an action with
predefined handlers. I mean, DialogAction does not have predefined
handlers at all (it has default getView() though). CRUDAction has
predefined handlers, it is based on DialogAction, thus it has full
power of two-phase request processing.
Yea, I really should be fair and look at your stuff longer. It's just so
overwhelming with all the technologies out there and different ways of
doing things... it just gives me a headache and I'm burned out doing it;)
and it is definitely a totally different paradigm
from all the Struts stuff out there.
Is this bad?
No, not if the shift yields good benefits, which I'm sure you will argue
the shift would provide and it's not fair for me to say it wouldn't
without looking into it further.
Not saying it's not a good concept,
I'm just stating that is more difficult to grasp at first since it's not
how Struts was desgined.
Right, so I suggest another way of doing things. I think, a better
way. But it is not a replacement for other Struts stuff, this is
merely an addition.
Well, I might beg to differ a bit there, I think it's a bit more than
'addition.'
*AND* it allows to build almost fool-proof UI with better user experience.
This part does interest me a lot.
ALSO I will amost GUARANTEE you that in reality you will almost always
end up having to do other things when an update/edit/delete takes
place...
This is just a base CRUDAction, subclass it if you need. But I believe
that it is good as it is for 90% cases.
Probably true.
Anyway, my version does not differ from other handlers.
Data is loaded from the backend by crudForm.crudLoadForUpdate()
method. This method has to load existing data either directly into
action form or into nested BO/VO.
But it does differ as to where this stuff is being done.
yes, stuff is done where it should be done in OO app - at the same
place where data is.
I could see arguments both ways. Seems to still be debate if doing
something like dao.update( someObject ) is better than doing
someObject.update() where the later takes care of updating itself. If
you could all that stuff to work without the stinking thing to have to
be so tied to Struts I'd jump on your stuff in a heartbeat (then again
JSF does manage this I believe). In other words I should be able to use
a generic object that does all the CRUD stuff you mentioned without it
having to be so tied to the Struts model. I'd love to be able to pull
your CRUDform out and use in a Swing app if I needed (possibly it can, I
don't have the code here at home right now).
On the other hand I already have CRUDComboAction (not in current
download), which combines both. I guess I need to replace former with
latter ;-)
Actually I think that would be a good idea. It definitely will make the
framework no chance of an 'addition' any more but I think that's a more
consistent approach to take. (I believe this is what WebWorks does and
is a similar approach to the backing bean concept in JSF?). Plus the
ActionForm is just sort of goofy anyway:) I just assume stick my single
VO in there anyway vs creating all those duplicate properties.
I often treat Action and ActionForm as part of one entity, so
sometimes I do stuff here, sometimes there. When both classes work in
pair (and they often do), this should not really matter. But I agree
with you, that more consistent approach would be better.
Yea, see if you can wrap into one. That would be pretty cool.
It is there: \dialogs\src\net\sf\dialogs\samples\crudaction
Ok, I'll look tomorrow.
JSF allows to easily set up for two-phase processing, you are right.
But it does not provide "web islands" mode, that is, when different
pages are delivered from the same web location. This allows to cut on
the browser page history. Also, JSF uses JSF. There are a lot of
people who want to continue using JSP, and not to invest in new
component technology. And by the way, speaking of components, Struts
Dialogs allows to create JSP Components with only one <jsp:include>.
Interesting and yea, I'm not convinced 'yet' to jump the Struts/JSP ship
yet. Although one thing I always have to consider is what technology is
going to put food on the table. I'm not a technology bigot so I don't
care that much if I'm coding .NET (which I haven't really touched yet)
as long as it's paying me. My idealistic days now seem behind me:(
People expect of Struts either to change or to die. I don't want it to
die, not yet, as well as I don't want to learn a new one, therefore I
created my stuff. But seems that it is easier to start off a new
framework, even if it is a spinoff off an existing one, than to try to
change what is considered "traditional" and "normal".
True.
First, I am not going anywhere, at least not now ;-) Second, I already
have pretty good documentation, and I will extend it and make it more
clear. If Struts Dialogs were accepted in Struts core, then the
suggested way would become a traditional way, and would be documented
and would have javadocs, etc. Also, if it became "normal", then
newbies will not quesion "why I should use this over that", they will
simply use it ;-)
I understand that veteran Struts users have their ways. I do not
suggest to change these ways, I am offering a choice of doing stuff
differently. Choice is good, is not it? Is not it the power of open
source?
Well said. I have to admit my initial reaction was "Oh here we go again,
another twisting of the framework or 'yet another frameork' in general"
and I had a knee jerk reaction - especially in regard to that it seemed
to be proposed to someone completely new to Struts and might have
confused him. Part of my initial reaction was grounded in that I
personally feel overwhelmed with the technologies out there. Just count
one day how many web frameworks are out there. This is the reason
actually that I'm going to start learning .NET stuff. I think what you
are proposing seems very exciting and I look forward to keeping tabs on
the progress, however I have this feeling (probably unfounded) that
companies are going to feel overwhelmed with the choices out there and
simply say "Screw it, I'll just go with an MS solution." They might even
be somewhat technical and still make the decision since there is
something to be said for using a technology that might be
less-than-ideal, but yet easier to find developers to code with it and
that understand it. (Although it can easily be argued that these 'run of
the mill' developers aren't going to be as smart as some guy that love
open source stuff.) I'm just trying to use my crystal ball and envision
how IT managers are going to think.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
