We're in the final stages of Tapestry 4.0, trying to fix the most glaring documentation ommissions, and tidy up the bug list.
I've finally written documentation for the script template specification DTD, which is a very important file with the growing emphasis on JavaScript with web applications.
Tapestry has had, for a few years, some very advanced code for generating dynamic JavaScript to complement the dynamic HTML. It's centered in these script templates that take care of organizing the JavaScript into two large blocks (one at the top of the page, the other at the bottom) ... which is better than having it scattered about. As importantly, the JavaScript generation understands the need for uniqueness, to prevent name collisions in client-side variables and functions. This is the infrastructure that lets clever folks, like the ones at Tacos, create Ajaxian components that just work without any special attention by the developer ... regardless of whether there's just one such component, or dozens, on a page. Tapestry has the infrastructure to support this, with out requiring any special configuration of servlets or anything else.
4 comments:
Just one comment about the script component that i find a bit annoying.
You need to have your javascript file in the classpath. You cannot give an asset or the path of js file in the application context.
So if you want a page to include only once a javascript file with some initialization you would use the script template specification. But you must include your js script file separately from the script template as the include-script property only includes script in the class path! It would be nice if the include-script could be smarter and accepts assets or context paths.
I can name a glaring hole in the Tapestry 4.0 documentation: the contrib library.
I know that Howard is not the creator of these components, but someone needs to provide thorough documentation on these components since they come as part of the standard Tapestry download.
I am currently trying to get the Tree component (or TreeView component) to work in Tapestry 4.0 with a data model that is dynamic. I found John Reynolds's TapestryTrees download, and that was good for getting started, but it assumes that you know the full structure of the tree at the time you create the model. Also the TreeNodeView subcomponent still uses a Tapestry 3.0 component specification. I am currently digging through the Workbench file system tree code, but there aren't any explanations as to why that code uses custom implementations of certain interfaces as opposed to the simple implementations that ship with the framework. I'd at least like to know what code gets called in what order and what the purpose of some of the interfaces are.
Sorry to vent like that, but it's been pretty frustrating.
Share my pain. I won't be documenting the Tree and would recommend that you use the Tacos Tree over the contrib Tree, since the latter does seem to be orphaned.
It's funny that you mention that Howard, as I was finally able to solve my contrib:TreeView problem.
It turns out that if you use a SimpleTreeDataModel, the nodes that you get from the TreeStateEvent's nodeUID() method are different instances that the nodes that are actually in the tree's data model. So you need a way to get the actual node (the one in the data model) from the event's node UID (which will be of the same type as your TreeNode subclass).
The easiest way to do this is to make sure your custom TreeNode implements hashCode() and equals() and then start at your data model's root node (ITreeDataModel.getRoot()) and search its children recursively for the node.
I'll give the tacos:Tree a try, hopefully it's easier to figure out. But now that I understand the contrib:TreeView better, it won't be a total waste of time because I learned a lot more about Tapestry 4.0 and Hivemind during this debugging session.
Post a Comment