Jason,
again thanks for your reply! To summarize it: everything can be
done but it isn't necessarily supported by Tapestry's directly
and easily - at least at the moment.
>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.
For a dynamic components it seems necessary to get rid of static
component specifications. I'd try that by creating an IComponent
implementation which
1. creates its ComponentSpecification in its constructor (or in
a factory method), and
2. sets it to itself with setSpecification().
Does this seem sensible?
>> 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).
A layout manager could be a specialized component that can be
attached to a container component. However, the layout manager
must not be a node in the normal component hierarchy: If component
A contains component B, and B gets a layout manager L attached, the
hierarchy should stay A -> B and not A -> L -> B. L should just be
a decorator of B.
A layout manager should just be a specialized decorator. A component
should be able to have a stack of decorators to perform user-visible
as well as user-invisible actions.
Does this seem sensible, too?
>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.
Looks good! However, I'd like Tapestry to have more support for what
you did and what I sketched. This regards the software to provide
supporting classes and the documentation to say something about
building dynamic hierarchies. (I am trying to start a project with
Tapestry. If that succeeds, I am willing to contribute.)
>Keep experimenting (that's the best way); you could start with a simple
>layout manager ;-)
I'll do that in the course of said project - provided I can get
the funding.
Best regards
Rainer Klute
Rainer Klute IT-Consulting GmbH
Dipl.-Inform.
Rainer Klute E-Mail: [EMAIL PROTECTED]
K�rner Grund 24 Telefon: +49 172 2324824
D-44143 Dortmund Telefax: +49 231 5349423
-------------------------------------------------------
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
