[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tapestry-user
Subject:    RE: How dynamic components could be created?
From:       Pavel Rezny <pare () tmapy ! cz>
Date:       2005-09-30 9:33:25
Message-ID: 433D0665.1060600 () tmapy ! cz
[Download RAW message or body]

	Thanks to everybody trying to help.

We've thought about every advice and found that, we need more dynamic 
than surround each form item in a special block and we do not want to 
bypass Tapestry logic in form handling. The ideal solution for us would 
be if there are filled request parameters and page properties when 
Delegates are called to create page template and specification.

	Can anybody find out if it is possible or Howard is only person who can 
say correct answer?

		Pavel


-----Original Message-----
From: Patrick Casey [mailto:patcasey@adelphia.net]
Sent: Tue 9/27/2005 10:06 AM
To: 'Tapestry users'
Subject: RE: How dynamic components could be created?


	I built some dynamic search forms that introspect the object being
displayed and set up the appropriate list of search widgets based on a
combination of the object properties and some metadata so it can definitely
be done. However, I couldn't find a good way to do it without essentially
shoving Tapestry into a corner and taking control of the process myself.

	So my search component spits out label and input fields via an
HTMLWriter and sets their IDs according to my (not Howard's) naming
convention. Then my form handler (for when the user clicks search) extracts
the values directly out of the session e.g.

		Enumeration en = cycle.getRequestContext().getRequest()
				.getParameterNames();
		while (en.hasMoreElements()) {
			String s = (String) en.nextElement();
			if (s is one of my magic fields)
				...

	It works great, but, since I'm not using Tapestry to set up the
fields for me, I can't use the OOB validation or binding code.

	--- Pat


>> -----Original Message-----
>> From: Pavel Rezny [mailto:pare@tmapy.cz]
>> Sent: Tuesday, September 27, 2005 7:34 AM
>> To: tapestry-user@jakarta.apache.org
>> Subject: How dynamic components could be created?
>> 
>> Hello,
>> we are a small group of developers creating a multilayer system that
>> will process databases and map applications. We decided to build
>> user-interface layer using Tapestry, and business-logic layer using
>> Spring. The specification of the project requests separating business
>> logic layer from user interface layer.
>> 
>> System architecture conforms, from our point of view, to MVC
>> (Model-View-Controller) design pattern. Spring components and business
>> logics create Model (data and metadata). Tapestry serves as interpreter
>> for the Model, and it creates View. Model is thus transferred from
>> business logic (Controller) to Tapestry components (View); it contains
>> data and metadata in the form of XML document. Model interpretation
>> provided by some components of Tapestry (eg. form or table) would enable
>> us generate from received data and metadata dynamic outputs.
>> 
>> Here we face difficulties. We tried to create dynamic Template and
>> Specification using Delegate class (Template-Source-Delegate,
>> Specification-Resolver-Delegate). But at this very moment neither page
>> instance exists, nor exist parameters, that should be passed between
>> pages in RequestCycle. We use PrepareForRender to retrieve our Model
>> from business logic layer.
>> 
>> Is there anybody to give us a piece of advice? Has Tapestry a solution
>> how such dynamic components could be created? (those that use data
>> passed by another layer) Can Delegate Template use parameters from
>> RequestCycle? Or can Delegete be invoked after PrepareForRender has been
>> processed?
>> 
>> We look forward to hearing your advice.
>> 
>> Thanks
>> 
>>     Jirka and Pavel
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]