>>Yes, you are correct in that your *component* hierarchies are >>statically defined in the spec. > > Hm, that means that Tapestry is in no way as flexible as e.g. AWT/Swing > where I can modify a Container on the fly as I which. I could e.g. add > Components (including Containers) to it, remove them, reorder them> etc. What is >it that makes Tapestry so limited? The static component > description files?
Well, yes and no. I'll try to clarify: the static component spec is just an easy way to describe the relationships between the individual components, and allow Tapestry to optimize object/component creation at runtime (Howard, correct me if I'm wrong). Some people on this list *have* built dynamic pages on the fly, and while it's possible, it requires a more intimate knowledge of Tapestry. Theoretically, you don't need anything except what's already there. You can get your dynamic behaviour by encoding it in a component. > I'd also like to have Tapestry an equivalent of a LayoutManager. In > AWT/Swing I can attach a LayoutManager to a Container which controls > the layout of the components. In Tapestry I am limited to a static > layout. Now while this not something you can do easily, it is something you can do. If you can dynamically create HTML (which Tapestry does support), then you aren't working with a static layout. The key is components (see below). >>However, there are several features of Tapestry >>(namely the Foreach, Block, and InsertBlock components) that allow you >>to dynamically insert code into your page. The key is to define the >>hierarchy in a Java model object, then create the proper components to >>render it. Breaking it down, each element of a hierarchy is simply a >>1-many relationship, which can be easily modelled with a Foreach.> > I think I understand how you did it. The problem is that you don't have > a 1:1 mapping between model and view, like in Swing (again). The latter > offers you e.g. a JTree component class to *view* a tree and a > TreeModel interface for the *model*. In Tapestry I have to fiddle > around quite a lot instead.> > If I am wrong (and I'd love to be wrong), please correct me! My insight > into Tapestry is still quite limited. Actually, I do have a 1-1 model-view mapping; in fact, I modelled it after Swing (in a way). I have an ITreeListNode interface that represents a node in the tree. Then, I have a *completely self-contained* component called TreeList that accepts a list of roots. The roots MUST implement the ITreeListNode. (OK - so I could have made a simple TreeListModel that wrapped the list of roots...). Either way - all the behavior can be wrapped and abstracted by creating a custom component that can be used exactly like the built-in components. If I could give you my code, you would specify the parameters, and build a tree just by implementing the model. >>I'm particularly busy now, but feel free to e-mail me if you'd like some >>more details, and I'll get back to you as soon as I can.> > I am grateful that you spent some time on my question at all. I just meant that it might take some time getting back to you... :-] Keep experimenting (that's the best way); you could start with a simple layout manager ;-) -jason ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ Tapestry-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tapestry-developer
