Could it be that people are trying to force an external sense of design from another system before understanding how this one works?
For example, you mention not being able to create links to wiki pages. If I were tasked with such a thing, I would probably create a "component" with a "page" parameter. You could store your wiki page content however you liked, all you have to do is find the best method for your uses and make the component serve it up. Or, are there other requirements needed that I've not understood? On 6/14/06, Stephen Todd <[EMAIL PROTECTED]> wrote:
My concern isn't so much about theming as it is to provide the ability to not have any idea of what component I might possibly use. I want to be able to drop in a jar that contains components into a certain folder and make the components available for use without having to write code( and maybe even without a restart). I want to be able to, for example, create a flexible system that has drop-in components (not in the tapestry sense, but in a systems sense) and be able to use those parts throughout the application just through live configuration. I think that the current setup excludes being able to make a wiki that has links to other pages. I need to be able to create components in a component on the fly. Stephen On Jun 14, 2006, at 10:34 AM, Howard Lewis Ship wrote: > JSF is having scalability problems because they don't use the > static structure model. > > There are other approaches. > > For example, if you have multiple skins, you could incorporate the > skin name into the page name. > > To be honest, I prefer Jesse's approach of supporting skins > primarily by changing stylesheets. That's incredibly powerful. > > Much of what Tapestry offers is based on it having a "map" of the > application; this map is the names of pages, and the ids of > components within pages (often nested within other components). > This map is how Tapestry bridges from the concept of actions to the > concept of components ... because a limited number of actions have > the ability to "name" pages and components to operate upon. > > > On 6/14/06, Stephen Todd <[EMAIL PROTECTED]> wrote: > Howard, > > I didn't want to start another debate on the list but I wanted to ask > personally. Could another solution be to also pool components in the > same way that pages are pooled? Then store a proxy for the component > tree such that the component is pulled from the pool when asked for > from the proxy. You could have a special proxy that allowed for the > component to be selected at run time based on the name of the > component. If the component wasn't loaded, this might incur a one > time setup cost, but you are going to have that some time anyway. > > To me, it would seem that the additional cost would be increased from > going by reference to searching through a short list of components > and then getting an object from the pool. You could separate this > into the special case proxy class so that the performance loss would > be localized to the dynamic component. > > I might have made some huge assumptions here, but sometimes the > mantra around here of "dynamic content, static structure" makes it > sound like the developers are stuck in a paradigm. I hope you don't > take that personally because I realize I am not as intimately > familiar with the code and I don't have much time right now to > contribute (though I would like to). I am impressed with the > framework and think its great — I just want it to be better. > > We are all busy, so I will understand if you don't want to explain. > There definitely isn't enough time for you to answer everyone's > concerns about each design decision. > > Thanks, > > Stephen > > > On Jun 13, 2006, at 2:39 PM, Howard Lewis Ship wrote: > > > This goes against the grain of Tapestry. > > > > Here's some copy from the new Tapestry 5 web site (not yet > > available) that > > conveys the reasoning behind this: > > > > Tapestry is designed to be extremely scalable in several dimensions: > > > > - Tapestry applications may contain many pages and many custom > > components. > > - Tapestry applications may contain very complex functionality. > > - Tapestry applications may be created by large, diverse teams. > > - Tapestry applications can service large numbers of concurrent > > users. > > > > One core architecture decision in Tapestry exists to service many > > of the > > above goals (and others that are harder to describe). *Static > > Structure, > > Dynamic Behavior* > > > > In Tapestry, the structure of any particular page is *static*. > This is > > necessary for several reasons, most importantly because Tapestry > > pages are * > > pooled*. Creating and Tapestry page is an involved process, because > > the page > > object is simply the root of a large tree of other objects > > including user > > provided components, many kinds of structural objects, template > > objects, and > > others. Creating a new page instance for each request is simply > not * > > scalable*. > > > > Instead, Tapestry *pools* pages. Once created, a page instance > will be > > stored in a pool for that particular type of page, and reused in > later > > requests. An incoming request, the result of a user clicking a > link or > > submitting a form, will be processed by *some* server within a > > cluster, and > > will use *some* page instance within the page pool. Because page > > instances > > are static and uniform across instances and servers, Tapestry can > > use any > > available page instance, or create a new one as needed. > > > > Tapestry does not need to store page instances inside the > > HttpSession. At > > most, it stores a smattering of *persistent properties* of the page > > in the > > session, but not the entire page instance. This lean use of the > > HttpSession > > is key to Tapestry's very high scalability, especially in a > clustered > > configuration. > > > > In some Tapestry-like frameworks, such as Faces and Wicket, the page > > structure is more dynamic, at the cost of storing much, much more > > data in > > the HttpSession. > > > > This static structure is not so limiting as you might think. With > > different > > kinds of conditional and looping components, and the ability to > > "jump out of > > the flow" and render components in an arbitrary order, you will not > > find > > Tapestry to be rigid ... anything but! > > > > > > > > > > On 6/13/06, James Sherwood < [EMAIL PROTECTED]> wrote: > >> > >> This is the situation: > >> > >> I would like to create a page in such a way that the jwcid's in > >> the html > >> are > >> standard but I can produce the html any way I wish. > >> > >> To do this there would have to be a way to pass tapestry the html > >> of a > >> page > >> from a database for instance. > >> > >> Something to the effect of a <jwc id="insertTapestry"/> in a page > >> which > >> inserts the html and tapestry tags but the html tags and tapestry > >> tags > >> that > >> are inserted are still rendered by the engine. > >> > >> Is this possible? > >> > >> Thanks, > >> James > >> > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > -- > > Howard M. Lewis Ship > > Independent J2EE / Open-Source Java Consultant > > Creator and PMC Chair, Apache Tapestry > > Creator, Jakarta HiveMind > > > > Professional Tapestry training, mentoring, support > > and project work. http://howardlewisship.com > > > > > -- > Howard M. Lewis Ship > Independent J2EE / Open-Source Java Consultant > Creator and PMC Chair, Apache Tapestry > Creator, Jakarta HiveMind > > Professional Tapestry training, mentoring, support > and project work. http://howardlewisship.com
-- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
