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]>
