Dumb Question about Project Layout
Ok, so I have 327 pages and 393 components in my application. (It's a crud tool so 20 things times 20 objects = 400 pages get automatically built) It's time to organize. So right now, I have: appname.pages appname.components There are hints here and there in the docs that if I add a package called: appname.pages.edit That I can move all pages with Edit at the beginning/end of their name into that package. I'm gathering that that's all I have to do, that Tapestry will then find things. But if I want, I can remove Edit from the name, because edit/foo and EditFoo are considered equivalent. edit/EditFoo will even work. Down the road, I can change references to edit/Foo if I feel like it. Is all that true? Are the rules the same for pages and components? (Using 5.2 trunk, btw, according to the Wiki there are some old bugs, but I don't really care about those) Pierce - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Dumb Question about Project Layout
Yes, the basic rule for pages is that the name, beneath the root pages package, is the logical page name. The logical page name appears in URLs. So class appname.pages.EditUsers will have a logical name of EditUsers. You can also create a subpackage (or sub-sub-package), for example: appname.pages.users.EditUsers -- users/EditUsers appname.pages.edit.EditUsers -- edit/EditUsers I tend to prefer the former, to group related pages by the data object (User) that they operate upon. Tapestry will do a little processing on the logical name to create aliases for the name. As you noted, it sees the redundancy in the name, so appname.pages.users.EditUsers -- users/EditUsers -- users/Edit appname.pages.edit.EditUsers -- edit/EditUsers -- edit/Users Tapestry looks for a suffix or a prefix that matches the containing package name. For page names (rather than component or mixin types) there's an extra step. A trailing /Index will be stripped off, if present. appname.pages.users.UsersIndex -- users/UsersIndex -- users/Index -- users Tapestry users the shortest of these when constructing the URL. Generally, I only care about these rules when I'm trying to follow on externally dictated URL scheme. Before I bring out the big guns (URLRewriter in 5.1, LinkTransformer in 5.2) I'll reverse-engineer my desired URLs into classes in the correct package. So if my client wants the URL to be /edit/user I might create class appname.pages.edit.EditUser. On Mon, Jun 7, 2010 at 2:44 PM, Pierce Wetter pie...@paceap.com wrote: Ok, so I have 327 pages and 393 components in my application. (It's a crud tool so 20 things times 20 objects = 400 pages get automatically built) It's time to organize. So right now, I have: appname.pages appname.components There are hints here and there in the docs that if I add a package called: appname.pages.edit That I can move all pages with Edit at the beginning/end of their name into that package. I'm gathering that that's all I have to do, that Tapestry will then find things. But if I want, I can remove Edit from the name, because edit/foo and EditFoo are considered equivalent. edit/EditFoo will even work. Down the road, I can change references to edit/Foo if I feel like it. Is all that true? Are the rules the same for pages and components? (Using 5.2 trunk, btw, according to the Wiki there are some old bugs, but I don't really care about those) Pierce - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com
Re: Dumb Question about Project Layout
On Jun 7, 2010, at 3:00 PM, Howard Lewis Ship wrote: Yes, the basic rule for pages is that the name, beneath the root pages package, is the logical page name. The logical page name appears in URLs. What is the rule for components? So class appname.pages.EditUsers will have a logical name of EditUsers. You can also create a subpackage (or sub-sub-package), for example: appname.pages.users.EditUsers -- users/EditUsers appname.pages.edit.EditUsers -- edit/EditUsers I tend to prefer the former, to group related pages by the data object (User) that they operate upon. Splitting by verb is working better for me. To each his own. :-) For my components, splitting by data object might be more logical, but I'm working that out. Tapestry will do a little processing on the logical name to create aliases for the name. As you noted, it sees the redundancy in the name, so appname.pages.users.EditUsers -- users/EditUsers -- users/Edit appname.pages.edit.EditUsers -- edit/EditUsers -- edit/Users Tapestry looks for a suffix or a prefix that matches the containing package name. Ok, so two conclusions. #1: if I move things down a package, that means that I'm changing the logical page name to include the new package name; that implies that references to the old name in .tml files will need newpackage/ prepended to any references. That is with pages.EditUser.java - pages.edit.EditUser.java: t:pagelink page=EditUser / Must be changed to one of the following: t:pagelink page=edit/User / t:pagelink page=edit/EditUser / That's not such a bad thing after all, that's similar to what happens if I pushed all the edit pages into a component library. #2: Tapestry will process the package name against the class name to reduce redundancy, so after the split I can leave the new package name in the class name so that I don't end up with multiple files named User.java for edit/User.java, list/User.java, but rather I can keep with EditUser.java, ListUser.java, and then it is more clear which is which. Are the rules similar for components? Pierce - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Dumb Question about Project Layout
On Mon, Jun 7, 2010 at 4:15 PM, Pierce Wetter pie...@paceap.com wrote: On Jun 7, 2010, at 3:00 PM, Howard Lewis Ship wrote: Yes, the basic rule for pages is that the name, beneath the root pages package, is the logical page name. The logical page name appears in URLs. What is the rule for components? The exact same rules, except for the /Index part. So class appname.pages.EditUsers will have a logical name of EditUsers. You can also create a subpackage (or sub-sub-package), for example: appname.pages.users.EditUsers -- users/EditUsers appname.pages.edit.EditUsers -- edit/EditUsers I tend to prefer the former, to group related pages by the data object (User) that they operate upon. Splitting by verb is working better for me. To each his own. :-) For my components, splitting by data object might be more logical, but I'm working that out. Tapestry will do a little processing on the logical name to create aliases for the name. As you noted, it sees the redundancy in the name, so appname.pages.users.EditUsers -- users/EditUsers -- users/Edit appname.pages.edit.EditUsers -- edit/EditUsers -- edit/Users Tapestry looks for a suffix or a prefix that matches the containing package name. Ok, so two conclusions. #1: if I move things down a package, that means that I'm changing the logical page name to include the new package name; that implies that references to the old name in .tml files will need newpackage/ prepended to any references. That is with pages.EditUser.java - pages.edit.EditUser.java: t:pagelink page=EditUser / Must be changed to one of the following: t:pagelink page=edit/User / t:pagelink page=edit/EditUser / That's not such a bad thing after all, that's similar to what happens if I pushed all the edit pages into a component library. #2: Tapestry will process the package name against the class name to reduce redundancy, so after the split I can leave the new package name in the class name so that I don't end up with multiple files named User.java for edit/User.java, list/User.java, but rather I can keep with EditUser.java, ListUser.java, and then it is more clear which is which. And that's the intent; although Java support having the exact same class name in multiple packages, it's something to be avoided. The naming transformations allow you to use reasonable class names AND have reasonable URLs. Are the rules similar for components? Pierce - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com
