Oh. Yeah, tiles XML is "OO".
Thanks for the correction!
.V
Martin Cooper wrote:
On Sun, 5 Jan 2003, V. Cekvenich wrote:
Craig wrote :
"I'm playing with more interesting
ideas like using Jelly scripts (or JSP pages) as Actions so you don't
have to write them in Java. "
If Actions, or anything goes XML (Jelly), or JSP, EL or generator (or
sometimes design patterns) we lose OO.
Not necessarily. XML is more a syntax than a language - it's what you do
with it that supplies the semantics. (This is part of its heritage - SGML
was designed specifically to avoid embedding of semantics in the original
document, which is why DSSSL was designed to provide those semantics.)
For example, look at Tiles. I can create a definition in XML, and then I
can create further definitions that 'extend' the first one.
Just as other languages such as Java and C++ can be used for object
oriented programming, XML can too. It just depends on how you use it.
--
Martin Cooper
OO gives us productivity as Java is OO capable, and some people use it
in OO way. (Similar issue in C++, some people use C++ in C mode, or what
I call object disoriented mode).
Unless there is a way I do not know of to make above (XML, el,
generators) be able to do:
- "is a / has a" (extends a base class, or has an extended helper object)
- inheritance and delegation (same as above) allows for after the fact
programing. After a developer thinks they are done with the scope,
*clients like to change the scope*, so when one has a baseAction or a
baseActionHelper, one can go to the base class and quickly maintain the
code, and not have to go to every place.
Java is OO capable, whereas above listed things AFAIK do not have that
productivity in maintenance mode.
Please take OO in consideration, it is a 10 fold advantage for the OO
Java practitioners. (It is not just overriding and polymorphisam. I
could give more real life examples. Like one base action that need to
act this way or another depedning on the situation.)
Same issue is for non Action cases. XML, or JSP, EL, generator, or
scripts (or sometimes design patterns) we could lose OO and flexibility.
(I can say in EL when you use this expresion here do it this way, BUT
over here, use the same expresion in another way)
(OT: I was told that Flash (when one does data entery screens in a Flash
plug in) can do limited OO)
.V
Craig R. McClanahan wrote:
On 4 Jan 2003, David M. Karr wrote:
Date: 04 Jan 2003 17:28:58 -0800
From: David M. Karr <[EMAIL PROTECTED]>
Reply-To: Struts Developers List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Another bright idea,
make "indexed" work with JSTL forEach and friends
"Craig" == Craig R McClanahan <[EMAIL PROTECTED]> writes:
Craig> On 4 Jan 2003, David M. Karr wrote:
>> Can anyone envision any other situations in the Struts code where indirect
>> references to the JSTL would be convenient? That, at least, could give us some
>> additional perspective on this.
Craig> General purpose access to the EL evaluator (which David used in
Craig> implementing the EL-ized versions of the Struts tag libraries) would
Craig> definitely be useful in general purpose computing environments. The Jelly
Craig> project (in jakarta-commons-sandbox) uses this kind of thing for EL-izing
Craig> the scripting environment that Jelly supports, for example.
Craig> It would be interesting to contemplate where you might usefully leverage
Craig> EL expressions ... say, in struts-config.xml constructs ...
Could we do this in DynaBean property value initializations?
That would certainly make sense, as long as we could identify the
"variable context" (in EL implementation terms) with which variable
references should be resolved.
I can't think of
any other places in the config file where this would be useful (yet).
At least one other place would be things like the pattern matching rules
in the <controller> element for calculating URLs.
Longer term (2.0 time frame probably), I'm playing with more interesting
ideas like using Jelly scripts (or JSP pages) as Actions so you don't have
to write them in Java. We also need a good high level multi-request
framework, and it might be useful there in automating some of the forward
and backward link references.
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>