struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "V. Cekvenich" ...@basebeans.com>
Subject Re: Another bright idea, make "indexed" work with JSTL forEach and friends
Date Sun, 05 Jan 2003 11:58:23 GMT
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.

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 <dmkarr@earthlink.net>
>>Reply-To: Struts Developers List <struts-dev@jakarta.apache.org>
>>To: struts-dev@jakarta.apache.org
>>Subject: Re: Another bright idea,
>>     make "indexed" work with JSTL forEach and friends
>>
>>
>>>>>>>"Craig" == Craig R McClanahan <craigmcc@apache.org> 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:struts-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>


Mime
View raw message