Thread: [Webwork-user] Name collision
Brought to you by:
baldree,
rickardoberg
From: Maurice C . P. <Ma...@Vi...> - 2000-12-06 17:13:33
|
Rickard, To try and explain this clearer I will denote jsp params by enclosing them in *'ss. I am having some problems implementing selectmap.jsp using *key* and *value* as variables. The problem is when the *key* has the same name as *name*. This causes every option to be CHECKED. This is because I can't figure out a way to explicitly access a parent property while at a child level. The only way I know how is to cause the name to miss at the child level. What I'm looking for is something like <webwork:property name="../$name"/> or <webwork:property name="/$name">. IIRC, this is how its done in XSLT. I was able to change one of the attribute names to get the example to work, but it may be an issue with with others. Following is the actual code that is causing the problem: I have added this class to test a collection with selectmap.jsp that looks like this: =========================================================== /* * WebWork, Web Application Framework * * Distributable under LGPL license. * See terms of license at opensource.org */ package webwork.test; import java.util.List; import java.util.ArrayList; import java.util.StringTokenizer; import java.io.InputStream; import java.io.InputStreamReader; import java.io.BufferedReader; import java.io.IOException; import webwork.ActionSupport; /** * A list of books * * @see <related> * @author <firstname> <lastname> (<email>) * @version $Revision: 1.2 $ */ public class BookList extends ActionSupport { // Attributes ---------------------------------------------------- static List books; static { // This never changes, so we do it once only books = new ArrayList(); class Book { String title; String author; String publisher; public String getTitle() { return title; } public void setTitle(String title) { this.title = title; } public String getAuthor() { return author; } public void setAuthor(String author) { this.author = author; } public String getPublisher() { return publisher; } public void setPublisher(String publisher) { this.publisher = publisher; } } // We read the values from a file so that it is easy to change try { InputStream resource = BookList.class.getResourceAsStream("books.txt"); BufferedReader in = new BufferedReader(new InputStreamReader(resource)); String bookInfo; while ((bookInfo = in.readLine()) != null) { StringTokenizer tokens = new StringTokenizer(bookInfo, ","); Book book = new Book(); book.setTitle(tokens.nextToken()); book.setAuthor(tokens.nextToken()); book.setPublisher(tokens.nextToken()); books.add(book); } in.close(); } catch (IOException e) { e.printStackTrace(System.err); System.err.println("Could not read list of books"); } } // Public -------------------------------------------------------- public List getBooks() { return books; } } =========================================================== I also added setAuthor() and getAuthor() to FormTestForm but didn't include them here (obvious implemention). =========================================================== <%@ taglib uri="webwork" prefix="webwork" %> <jsp:include page="/template/standard/controlheader.jsp" flush="true"/> <select name="<%=request.getParameter("name")%>"> <webwork:iterator name="$list"> <option value="<webwork:property name="$key"/>" <webwork:equals name="$key" value="$name">SELECTED</webwork:equals> > <webwork:property name="$value"/> </option> </webwork:iterator> </select> <jsp:include page="/template/standard/controlfooter.jsp" flush="true"/> =========================================================== Added this to formtest.jsp: =========================================================== <jsp:include page="BookList.action?result=/template/standard/selectmap.jsp" flush="true"> <jsp:param name="label" value="Book:"/> <jsp:param name="name" value="author"/> <jsp:param name="list" value="books"/> <jsp:param name="key" value="author"/> <jsp:param name="value" value="title"/> </jsp:include> Later, Maurice |
From: Rickard <ri...@jb...> - 2000-12-08 09:17:55
|
Hi! "Maurice C . Parker" wrote: > To try and explain this clearer I will denote jsp params by enclosing them in *'ss. <snip> Very good question. How to solve? Here's one idea: results can be bound to request attributes (by using the "id" tag attribute). It would be possible to use a scoping notation to explicitly refer to an entry point: <webwork:property name="hasBar" id="foo"> <webwork:property name="xyzzy:hasBar" id="xyzzy"> <webwork:property name="foo@bar"/> <!-- explicitly get the bar from foo, even though the normal scoping rules would have stopped at xyzzy --> </webwork:property> </webwork:property> Seems ok? This can be used with params too I think: <webwork:property name="hasBar" id="foo"> <jsp:include page="FooListElementsHasBar.action?list.jsp" flush="true"> <jsp:param name="name" value="xyzzy"/> <jsp:param name="label" value="foo@bar"/> <jsp:param name="value" value="bar"/> </jsp:include> </webwork:property> list.jsp --- <!-- xyzzy is iterator attribute of FooList. Elements have "bar" attribute, so we need to scope -> <webwork:iterator name="xyzzy"> <!-- Show value of foo@bar, and also print out xyzzy elements' bar value --> <webwork:property name="$label"/>:<webwork:property name="$value"/> </webwork:iterator> --- I think the above allows arbitrary scoping. And it also allow included pages to refer to any attribute of any property in parent page (without this scoping the child included pages can only refer to attributes in the result!). Seems ok. Any flaws with? Pros/cons? /Rickard -- Rickard Öberg Email: ri...@jb... |
From: Rickard <ri...@jb...> - 2000-12-08 16:29:35
|
(Maurice, gotta send emails to webwork-user, not me personally ;-) "Maurice C . Parker" wrote: > > I think the above allows arbitrary scoping. And it also allow included > > pages to refer to any attribute of any property in parent page (without > > this scoping the child included pages can only refer to attributes in > > the result!). > > > > I think that being able to refer to parent pages is *very* important. I'm glad that this may be coming soon. Just to clarify, you would be referring to the parent action and not the parent view, right? Yes. But you can do this today, as we do it all the time with the generic controls. Of course. But there's no way currently to reference beans from iterator, property, bean or similar tags. > > Any flaws with? Pros/cons? > > Would the id parameter do the upward search the same way that the name parameter does today? If so, we could potentially still have name collisions, this time on the id parameter instead of the name parameter. The "id" attribute is just a way to place a tag value into the page context under a name. E.g.: <webwork:iterator id="foo"> <%=pageContext.getAttribute("foo")%> </webwork> If you use included pages you need to make sure that the parent page doesn't use an id name that is going to be overwritten by the child page. > Since we are dealing hierarchial data maybe taking a look at some of the XML syntaxes isn't such a bad idea. Maybe X-Path or XSLT? These technologies have had to deal with problem already and may have some good ideas. > > The @ syntax is confusing me. Using the hierarchy below: > > Main.action > | > +--name > +--address (iterator) > | | > | +--name > | +--street > | +--city > | > (main.jsp) > | > +--Message.action > | | > | +--name > | +--subject > | +--text > | | > | (message.jsp) > | | > | +--Message.action > | | | > | | +--name > | | +--subject > | | +--text > | | | > | | (message.jsp) > | | | > | +--Message.action > | | | | > . . . . > . . . . > . . . . > > How to I address the name element of the Main.action while using address as an iterator? This example is the same problem as the original control problem. You would use "result@name" for Main.name "address@name" for the address iterator elements (if you use the id="address" attribute on the iterator tag that is), and so on. > Inside the Message.action recursion, is it possible to access the parent actions elements? Yes. The parent is bound to "parent.result" attribute. > Inside of these, would it be possible to specify the name on the first address? Yes, see above. > Pretty harsh (but hopefully not unfair) examples. I don't just don't want to see us get locked into a syntax that can't be flexible as the rest of Webwork has so far proven to be. Same here :-) Let's think about this some more. Test with more tricky examples, etc. But so far it seems ok. regards, Rickard -- Rickard Öberg Email: ri...@jb... |
From: Rickard <ri...@jb...> - 2000-12-12 16:02:15
|
"Maurice C . Parker" wrote: > To try and explain this clearer I will denote jsp params by enclosing them in *'ss. > > I am having some problems implementing selectmap.jsp using *key* and *value* as variables. The problem is when the *key* has the same name as *name*. This causes every option to be CHECKED. This is because I can't figure out a way to explicitly access a parent property while at a child level. The only way I know how is to cause the name to miss at the child level. > > What I'm looking for is something like <webwork:property name="../$name"/> or <webwork:property name="/$name">. IIRC, this is how its done in XSLT. Support for name scoping has been added to CVS. Here's how it works: You can use relative scoping using "..". ".." moves one object up in the chain of objects to try and find the name in. Example: "..:name" You can use absolute scoping using @. The left part is a named attribute in the request object, and the right part is the name of the property. Example: "foo@bar:xyzzy" Here's a snippet from a test I added to WebWorks test.jsp: <webwork:bean name="webwork.test.Person" id="rick"> <webwork:param name="name" value="Rickard"/> <webwork:bean name="webwork.test.Person"> <webwork:param name="name" value="Maurice"/> name=<webwork:property name="name"/><BR> ..:name=<webwork:property name="..:name"/><BR> rick@name=<webwork:property name="rick@name"/><BR> </webwork:bean> </webwork:bean> --- We declare to Person beans, which has a property "name" that we want to access. The declarations are nested, so both will be put on the "value stack" (BTW, the whole name/value resolution code has been rewritten. Much simpler/cooler/faster now, and works the way it should've from the beginning). The outermost Person is Rickard, and the inner one is Maurice. So, when we access the property named "name" it will go upwards in the value stack, and find it in the bean named "Maurice". The second property is named "..:name", which means that before we even start looking for "name" we skip the first value on the value stack. The bean found is hence the bean named "Rickard". The last property accessed is "rick@name". Since we use the absolute form of names (using @) we first get the value associated with the request attribute "rick". In our case we have bound this to the "Rickard" bean by setting the id of the first bean tag to "rick". WebWork then resolves "name" relative to this, which means that it will get "Rickard" as result. So, to conclude the result of the above is: name=Maurice<BR> ..:name=Rickard<BR> rick@name=Rickard<BR> Is this sufficient as naming rules? BTW, you can of course use .. as many times as you want: "..:..:..:foo" is ok. However, you can only use @ in the beginning of a name. "foo:bar@xyzzy" is not ok and will be resolved as "foo":"bar@xyzzy". regards, Rickard -- Rickard Öberg Email: ri...@jb... |
From: Maurice C . P. <Ma...@Vi...> - 2000-12-12 19:38:35
|
* Rickard Öberg (ri...@jb...) wrote: > > Is this sufficient as naming rules? It looks great! The only thing that I think might be desirable is using a : in the first position of the name to denote the top object in the object hierarchy. For example ":foo:bar" would get you into the second level no matter how deep you are. This is the same way that hierarchial filesystems work (just with slashes instead of colons). I haven't had a chance to look at the new name resolution code, so I'm not sure that this even makes sense. Why functionality like this might be attractive to me is the Jive/Webwork breeding I'm doing. If you look at the threaded messages, they are recursive in nature. I could be at any level but still need info from the original bean. Here is the code that I use to thread the messages (actually it needs to go deeper when before going to production): <webwork:iterator name="discussion"> <%@ include file="message.jsp" %> <ul> <webwork:iterator> <%@ include file="message.jsp" %> <ul> <webwork:iterator> <%@ include file="message.jsp" %> <ul> <webwork:iterator> <%@ include file="message.jsp" %> </webwork:iterator> </ul> </webwork:iterator> </ul> </webwork:iterator> </ul> </webwork:iterator> Here is message.jsp: <p> <span class="messageSubject"><webwork:property name="subject"/></span> <br> <span class="messageByline">Posted by <webwork:property name="user:username"/>, <webwork:property name="fancyDate"/>.</span> <br> <span class="messageBody"><webwork:property name="body"/></span> <br> <span class="messageReply"> ( <a href="CommentForm.action?forumID=<webwork:property name="forumID"/>&threadID=<webwork:property name="forumThread:ID"/>&messageID=<webwork:property name="ID"/>"/>Reply to this comment.</a> ) </span> <br> </p> In the link that I recreate at the end, I am using the the property forumID. This is from the original action bean and I think that the upward search is hurting my performance. If I were able to use name=":forumID", there is some potential to save cycles. BTW, I did use jsp:include tag for all those message.jsp's (about 15 at the time) and it didn't take me long to replace them with the include directive (ouch! 8-). It helped, but my performance is still way below what is typical for the Jive code heavy JSP's (Vodka skin for those who speak Jive 8-). I haven't had a chance to do any profiling or anything to see if it is something that I did in my action bean or if it is Webwork that's slowing me down. The parameter parsing stuff is the first thing that came to mind, only because it gets hit so heavily. After I typed all this it occurred to me that maybe I can us the @ syntax to get to the original action bean, I just don't know how to do it. If that's the answer, a little code snippet could probably get me there. Later, Maurice |
From: Rickard <ri...@jb...> - 2000-12-13 07:00:01
|
Hi! "Maurice C . Parker" wrote: > It looks great! The only thing that I think might be desirable is using a : in the first position of the name to denote the top object in the object hierarchy. For example ":foo:bar" would get you into the second level no matter how deep you are. This is the same way that hierarchial filesystems work (just with slashes instead of colons). I haven't had a chance to look at the new name resolution code, so I'm not sure that this even makes sense. I could easily add :foo to get to the top. There would be no significant performance penalty to do this. > After I typed all this it occurred to me that maybe I can us the @ syntax to get to the original action bean, I just don't know how to do it. If that's the answer, a little code snippet could probably get me there. Do this in the beginning of the top JSP: <webwork:property id="foo"/> Since there is no "name" attribute WebWork will take the first value on the value stack, which at the beginning happens to be the action itself. This will then be bound to the attribute name "foo". Which you then can access with "foo@". I can still add the ":foo" convention, but the above should help you. /Rickard -- Rickard Öberg Email: ri...@jb... |
From: Maurice C . P. <Ma...@Vi...> - 2000-12-13 15:57:51
|
* Rickard Öberg (ri...@jb...) wrote: > Hi! > > I could easily add :foo to get to the top. There would be no significant > performance penalty to do this. > Please, please, please do. Even thought the ":" and ".." aren't very intuitive either, at least there is president for this syntax. People can say, "Oh, it's just like a file system except I use a colon instead of a forward-slash." Thanks! Maurice |
From: Rickard <ri...@jb...> - 2000-12-13 16:02:09
|
"Maurice C . Parker" wrote: > * Rickard Öberg (ri...@jb...) wrote: > > Hi! > > > > I could easily add :foo to get to the top. There would be no significant > > performance penalty to do this. > > > Please, please, please do. Even thought the ":" and ".." aren't very intuitive either, at least there is president for this syntax. People can say, "Oh, it's just like a file system except I use a colon instead of a forward-slash." Done. Or at least I have it done locally. Not sure if I've committed it properly yet. I'm working on a revamped "month list test" and will commit it for sure when that's done. /Rickard -- Rickard Öberg Email: ri...@jb... |