Re: Nested-EL
Edgar P Dollin wrote: Everyone has preferences but in my opinion JSTL doesn't hold a candle to the nested tags, especially customized nested tags. I do agree however that JSTL for nested tags is not that important. It does help in environments where there is ZERO tolerance for JSP expressions Conveniently ignoring the fact that something like nested:write property=foo.bar/ stll contains a JSP expression -- just not a *standard* JSP expression :-). But something like... nested:nest property=foo nested:write property=bar / /nested:neste ...is back to standard JSP expression. :P Arron. or that are running older versions of the servlet container. Definitely. Edgar Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nested-EL
--- [EMAIL PROTECTED] wrote: Back in September, David Karr was threatening to do Tiles-EL and Nested-EL. I see that the Tiles-EL has been committed, sweet. Nested-EL seems to be missing. David, have you started working on Nested-EL? If so, how far off is it from being complete? If not, do you have any tips, because I am getting started on it tonight. Doesn't the EL replace the need for a nested tag library? Isn't the EL syntax easier than using nested tags? I haven't used Nested but it seems like a Nested-EL is redundant. IMHO, I'd say EL is actually harder, but at any rate EL can't completely do what the nested tags can. Like anything recursive. I just had an email conversation with a developer in England that has an app which business data model is a very large data structure. Depending on the level and required feature of the interface, they just have an include file for nested markup at any given level. The root JSP page simply includes the level for the given point and away it goes, regardless of its place in the hierarchy, and it's all updatable to the server because the actual property is made behind the scenes. This is only possible with the nested context being passed in the request. I put an OO-JSP spiel on my site, and this appears to be an extreme implementation of it. I know they're not everyone's cup of tea, but it's a hammer that can hit some pretty wicked nails. Arron. David Carl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
EL evaluation performance...
Peoples (Dave?), Just curious as to how quickly the EL tag logic identifies that there is in fact stuff to evaluate? Any micro-benchmarks? If there's no real overhead, especially for properties provided without expression, to just use them in the tags as-is. Or at least the nested tags where the internals aren't as deep as the rest. Arron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23827] - Make Nested-EL tags
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23827.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23827
Make Nested-EL tags
--- Additional Comments From [EMAIL PROTECTED] 2003-10-17 07:45 ---
To make it clear for me, the EL takes the provided expression and simply
translates it. This is then intended to be evaluated into the nested context?
My expectation:
Taking this nested markup...
nested:nest property=firstProperty
nested:nest property=secondProperty
nested:write property=${param.propName} /
/nested:nest
/nested:nest
...and the param to be colour as above, it would make the following property
in the nested context...
firstProperty.secondProperty.colour
...and if the param value was ../something it would be...
firstProperty.something
I'm assuming that this is the intended behavior.
NOTE: before it hits any kind of realease it needs to be tested with the iterate
tag. This is the only nested tag that needs to manipulate the indexed and mapped
properties to have [i] or (key) automatically into the property. First
thoughts say it should be fine, but a test would be spiffy to confirm it.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using Eclipse to contribute to Struts
But not lot of text to go with it! -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 -Original Message- From: Steve Raeburn [mailto:[EMAIL PROTECTED] Sent: 17 October 2003 06:53 To: Struts Developers List Subject: RE: Using Eclipse to contribute to Struts James' version uses 'Check out As...' rather than 'Check out as Project'. That's probably better as you can set up the classpath and get the code completion feature etc. working more easily. My notes don't cover that at all so use his first. And he has pretty pictures :-) Steve -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] Sent: October 16, 2003 10:33 PM To: 'Struts Developers List' Subject: RE: Using Eclipse to contribute to Struts Here's a little something I put together also: http://www.struts-atlanta.org/helping-develop-struts/index.html -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 678.910.8017 AIM:jmitchtx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority Visit our website at http://www.rbs.co.uk/CBFM/ *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using Eclipse to contribute to Struts
Thank you all for your help. I'm now configured. On Friday, October 17, 2003, at 05:18 AM, PILGRIM, Peter, FM wrote: But not lot of text to go with it! -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 -Original Message- From: Steve Raeburn [mailto:[EMAIL PROTECTED] Sent: 17 October 2003 06:53 To: Struts Developers List Subject: RE: Using Eclipse to contribute to Struts James' version uses 'Check out As...' rather than 'Check out as Project'. That's probably better as you can set up the classpath and get the code completion feature etc. working more easily. My notes don't cover that at all so use his first. And he has pretty pictures :-) Steve -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] Sent: October 16, 2003 10:33 PM To: 'Struts Developers List' Subject: RE: Using Eclipse to contribute to Struts Here's a little something I put together also: http://www.struts-atlanta.org/helping-develop-struts/index.html -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 678.910.8017 AIM:jmitchtx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority Visit our website at http://www.rbs.co.uk/CBFM/ *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts-chain Behavior Discussion
Hello, I get the distinct feeling that the committers point of view on the controller component of Struts is quite similar to Henry Fords point of view on the color of his cars. ...The controller component can be based on any arqitecture at all as long as its Command Chains... I realize that at some point a path must be choosen and code written. Ideas and conjecture about how many design patterns could be applied to the problem are insufficient. Craig has written code and Ted likes it so a path has been choosen, code written. No problem. Life is good. I don't doubt the proof of concept or the reasoning behind it. I am concerned about the acceptance of other ideas and other code (I have already said ideas are not enough). Prior to this extensive thread I have submitted code which fits squarely inside the controller component of the Struts MVC arquitecture. I requested comments on the code and received none. I might have expected constructive criticism, obsevations or even recognition of merit... but needed. But indifference was quite surprising. In light of the discussion within this thread I see the problem. My code contribution doesn't fit the expected pattern. Yes, that's a play on words. Indulge me for just a few more minutes. I formally request that a committer look at the code/doc I have contributed. Yes, I understand that you are volunteers and that you have no obligation to do so. If someone should decide to respond I thank you in advance. This is also my last request for comments. Here is why I believe that the code is of interest to the Struts community: * The approach requires an absolute minimum amount of integration with existing Struts code. The approach requires an essentially trivial refactoring of the RequestProcessor. I repeat, REFACTORING, not a new or modified behavior RequestProcessor. Since even refactoring would not be doing the right thing. In lieu of that, a Coomand adapter can probably be used. * Much has been said about coupling between actions. I claim that there is no coupling between actions using the approach. Comments are welcome. * Much has been said about mixing business logic with actions. I claim that the approach does not mix business logic with actions nor does it encourage it. Comments are welcome. * The approach does not require a developer to choose this approach over other, differing approaches. Mixing and matching is fine. * The approach is aimed toward reusable Struts controller components. Here, I'm refering to the MVC controller in the general sense not to the Struts servlet controller. Comments are welcome. Here is the link to the code and documentation. https://www.sistemas-jasper.com/indexStrutsActionWrappers.htm. John A. Sessler - Do you Yahoo!? The New Yahoo! Shopping - with improved product search
RE: EL evaluation performance...
-Original Message-
From: Arron Bates [mailto:[EMAIL PROTECTED]
Peoples (Dave?),
Just curious as to how quickly the EL tag logic identifies
that there is in
fact stuff to evaluate?
Any micro-benchmarks?
Sorry, I don't know of any benchmarks for this.
If there's no real overhead, especially for properties
provided without
expression, to just use them in the tags as-is. Or at least
the nested tags
where the internals aren't as deep as the rest.
I'm sure there would be some overhead, but I would imagine that a simple
string search for ${ would determine whether any evaluation needs to
be done. That couldn't be that expensive.
The principal reason why I've implemented the EL libraries as wrappers
over the regular libraries, as opposed to making the EL evaluation calls
in the regular library (like you seem to be suggesting we do for
nested-el), is that when JSP 2.0 is available, users can just change
their taglib directive to point back to the regular library (I now
recommend that people use the original prefix, not the -el prefix),
and the EL library can just be ignored. If we integrated the EL calls
into the regular library, you'd have to go in and remove those calls and
generate new release of the regular library, because you'd want the JSP
container to handle that work.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Using [myIDE] to contribute to Struts
I'd hate to set off a tree of discussions for all the different IDE's, but I just have to ask: Does anyone here have a similar guide for Intellij IDEA? Maybe we can devote a page for these guides (or links to them) in the Struts Wiki. Hubert -Original Message- From: Steve Raeburn [mailto:[EMAIL PROTECTED] Sent: Thursday, October 16, 2003 11:22 PM To: Struts Developers List Subject: RE: Using Eclipse to contribute to Struts I wrote an answer, but it got a bit long for this list, so I posted it on my web site for Hien and anyone else who's interested. http://www.ninsky.com/struts/eclipse.html Steve -Original Message- From: Hien Q Nguyen [mailto:[EMAIL PROTECTED] Sent: October 16, 2003 7:50 PM To: Struts Developers List Subject: Re: Using Eclipse to contribute to Struts Hi Indrajit, Thanks for replying. The link that you mentioned is geared toward more of Struts Users. I'm actually interested in getting Struts source code from the CVS repository and set up a project in eclipse so that I can tinker with Struts source code and soon hopefully I'd be able to contribute. I guess what I want to know is if any Struts developer uses Eclipse as their IDE for the development of Struts. If so, what is your set up like? Thanks, --Hien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts-chain Behavior Discussion
Here is why I believe that the code is of interest to the Struts community: There are many extensions of interest to the Struts community, and we maintain a resource page to help people find them. In practice, when an extension becomes very popular within the community, and it's obvious that there will be people around to maintain the extension, then someone has added it to the core. The Validator, Tiles, and Nested, all came about this way. So, the people to lobby aren't so much the Committers, but the Users. If a good number of people in the community, which includes the Committers, start using an extension like this, then it will probably find its way into the distribution. Darwin decides. Personally, I believe in keeping the core distribution as light as possible. That's one reason I still haven't made my own Scaffold package part of the core. It's also the reason we started places like Struts SourceForge. -Ted. john sessler wrote: Hello, I get the distinct feeling that the committers point of view on the controller component of Struts is quite similar to Henry Fords point of view on the color of his cars. ...The controller component can be based on any arqitecture at all as long as its Command Chains... I realize that at some point a path must be choosen and code written. Ideas and conjecture about how many design patterns could be applied to the problem are insufficient. Craig has written code and Ted likes it so a path has been choosen, code written. No problem. Life is good. I don't doubt the proof of concept or the reasoning behind it. I am concerned about the acceptance of other ideas and other code (I have already said ideas are not enough). Prior to this extensive thread I have submitted code which fits squarely inside the controller component of the Struts MVC arquitecture. I requested comments on the code and received none. I might have expected constructive criticism, obsevations or even recognition of merit... but needed. But indifference was quite surprising. In light of the discussion within this thread I see the problem. My code contribution doesn't fit the expected pattern. Yes, that's a play on words. Indulge me for just a few more minutes. I formally request that a committer look at the code/doc I have contributed. Yes, I understand that you are volunteers and that you have no obligation to do so. If someone should decide to respond I thank you in advance. This is also my last request for comments. Here is why I believe that the code is of interest to the Struts community: * The approach requires an absolute minimum amount of integration with existing Struts code. The approach requires an essentially trivial refactoring of the RequestProcessor. I repeat, REFACTORING, not a new or modified behavior RequestProcessor. Since even refactoring would not be doing the right thing. In lieu of that, a Coomand adapter can probably be used. * Much has been said about coupling between actions. I claim that there is no coupling between actions using the approach. Comments are welcome. * Much has been said about mixing business logic with actions. I claim that the approach does not mix business logic with actions nor does it encourage it. Comments are welcome. * The approach does not require a developer to choose this approach over other, differing approaches. Mixing and matching is fine. * The approach is aimed toward reusable Struts controller components. Here, I'm refering to the MVC controller in the general sense not to the Struts servlet controller. Comments are welcome. Here is the link to the code and documentation. https://www.sistemas-jasper.com/indexStrutsActionWrappers.htm. John A. Sessler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/doc/resources extensions.xml views.xml
mrdon 2003/10/17 19:45:53 Modified:doc status.xml doc/resources extensions.xml views.xml Log: Updated links to several struts.sf.net projects Revision ChangesPath 1.46 +3 -3 jakarta-struts/doc/status.xml Index: status.xml === RCS file: /home/cvs/jakarta-struts/doc/status.xml,v retrieving revision 1.45 retrieving revision 1.46 diff -u -r1.45 -r1.46 --- status.xml15 Sep 2003 12:23:04 - 1.45 +++ status.xml18 Oct 2003 02:45:52 - 1.46 @@ -171,8 +171,8 @@ lia href=http://strutstestcase.sourceforge.net/;TestCase/a/li lia href=http://stxx.sourceforge.net;Stxx/a (XLST)/li lia href=http://www.livinglogic.de/Struts/;Workflow/a/li -lia href=http://struts.sf.net;Cocoon Plugin/a/li -lia href=http://struts.sf.net;Scriptable Actions using BSF/a (Bean Scripting +lia href=http://struts.sf.net/struts-cocoon/;Cocoon Plugin/a/li +lia href=http://struts.sf.net/struts-bsf/;Scriptable Actions using BSF/a (Bean Scripting Framework)/li /ul /li 1.16 +1 -1 jakarta-struts/doc/resources/extensions.xml Index: extensions.xml === RCS file: /home/cvs/jakarta-struts/doc/resources/extensions.xml,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- extensions.xml9 Sep 2003 17:49:20 - 1.15 +++ extensions.xml18 Oct 2003 02:45:52 - 1.16 @@ -15,7 +15,7 @@ pa href=http://struts.sf.net/strutsdoc/;strongStrutsDoc/strong/a - A JavaDoc-type documentation tool for Struts and Struts-related configuration files/p pa href=http://www.twdata.org/struts-wildcard/;Wildcard-Matched Actions/a by Don Brown - Allows wildcards to be used in Struts 1.1+ action mappings./p pa href=http://alphaworks.ibm.com/tech/strutsscripting;Struts Action Scripting/a by IBM AlphaWorks - a Struts plug-in that allows development of Struts actions using the power and simplicity of any favorite scripting language./p -pa href=http://struts.sf.net;strongScriptable Actions/strong/a by Don Brown - Allows Struts Actions to be written in the scripting language of one's choice rather than as Java classes. It uses the a href=http://jakarta.apache.org/bsf;Beans Scripting Framework/a to allow scripts to be written in any language BSF supports like Python (using a href=http://www.jython.org/;Jython/a), Ruby (using a href=http://jruby.sourceforge.net/;JRuby/a), JavaScript (using a href=http://www.mozilla.org/rhino/;Rhino/a), or a href=http://www.beanshell.org;BeanShell/a./p +pa href=http://struts.sf.net/struts-bsf/;strongScriptable Actions/strong/a by Don Brown - Allows Struts Actions to be written in the scripting language of one's choice rather than as Java classes. It uses the a href=http://jakarta.apache.org/bsf;Beans Scripting Framework/a to allow scripts to be written in any language BSF supports like Python (using a href=http://www.jython.org/;Jython/a), Ruby (using a href=http://jruby.sourceforge.net/;JRuby/a), JavaScript (using a href=http://www.mozilla.org/rhino/;Rhino/a), or a href=http://www.beanshell.org;BeanShell/a./p pa href=http://jcorporate.com/;strongExpresso 5.0.3/strong/a by jCorporate - Expresso provides a foundation set of reusable, standards-based Java software components designed to shorten time-to-delivery of Web applications, and is integrated with the Struts framework. See also a href=http://www.xenonsoft.demon.co.uk/products/java.html;Best Practice with Expresso Framework 4.0/a./p pa href=http://sourceforge.net/projects/imagebuttonbean/;strongImageButtonBeanManager/strong/a by Ken Fitzpatrick. Combines the HTML Image Tag and the ImageButtonBean class in a manner analgous to the Struts HTML Submit Tag./p pa href=http://dynclass.sourceforge.net/;strongdynclass.sourceforge.net/strong/a by John Raley. A Class-creation API with very simple but powerful Map-to-JavaBeans translation/p 1.10 +1 -1 jakarta-struts/doc/resources/views.xml Index: views.xml === RCS file: /home/cvs/jakarta-struts/doc/resources/views.xml,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- views.xml 9 Sep 2003 17:49:20 - 1.9 +++ views.xml 18 Oct 2003 02:45:52 - 1.10 @@ -12,7 +12,7 @@ pa href=strong/strong/a - /p -- section name=Presentation Systems -pa href=http://struts.sf.net;strongCocoon Plugin/strong/a by Don Brown. Integrates a
cvs commit: jakarta-struts/src/share/org/apache/struts/config ActionConfigMatcher.java
mrdon 2003/10/17 19:48:16
Modified:src/share/org/apache/struts/config ActionConfigMatcher.java
Log:
Better error checking
Revision ChangesPath
1.3 +1 -1
jakarta-struts/src/share/org/apache/struts/config/ActionConfigMatcher.java
Index: ActionConfigMatcher.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/config/ActionConfigMatcher.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ActionConfigMatcher.java 10 Oct 2003 23:19:57 - 1.2
+++ ActionConfigMatcher.java 18 Oct 2003 02:48:16 - 1.3
@@ -110,7 +110,7 @@
String path;
for (int x = 0; x configs.length; x++) {
path = configs[x].getPath();
-if (path.indexOf('*') -1) {
+if (path != null path.indexOf('*') -1) {
if (path.length() 0 path.charAt(0) == '/') {
path = path.substring(1);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
