On Sun, Apr 8, 2012 at 6:32 AM, Nicolas LE BAS <[email protected]> wrote:
> So you're basically trying to render a form for generically editing a java
> bean, while looking up the bean properties by reflection. A complex
> situation indeed.
>
It doesn't seem that complicated... by I still have a high level of
enthusiasm ;).
> On 12-04-07 10:19 PM, Ken McWilliams wrote:
>
>> I'm not sure how tiles works exactly... each jsp renders its view and then
>> is composed into a single document? If so, is it possible to alter the
>> template while the JSPs are rendering?
>>
>
> Tiles works like some sort of elaborate jsp:include: a "view" is a tiles
> definition associated with a template (a JSP) and attributes (expressions).
> The template jsp:includes the attributes. Except you can define inheritance
> on the tiles definition and override the attributes of the parent, like you
> would with methods on a java class. Or you can override the attributes at
> runtime.
>
I've used tiles as a user for a couple years but for simple stuff... hmm I
can override the attributes at runtime but only before a the tiles render,
once it starts there is nothing I can do during rendering, right?
> I'm not sure exactly how much tiles would help in your situation, that
> would depend on how much code can be reused between various "type" editors.
>
> What I would do is:
>
> 1. one tile definition for each type / each editing mode. That's where
> Tiles can help you in not duplicating the code. Then you could do something
> like:
>
>
> <ken:typedefinitions name="basicSet">
> <s:iterator value="#both" var="cur">
> <s:if test="getters.contains(cur) && setters.contains(cur)">
> <tiles:insertDefinition name="editor.${cur.type}.rw">
> <tiles:putAttribute name="value" expression="${cur.value}"/>
> </tiles:insertDefinition>
>
> </s:if>
> <s:elseif test="getters.contains(cur)">
> <tiles:insertDefinition name="editor.${cur.type}.r"/>
> <tiles:putAttribute name="value" expression="${cur.value}"/>
> </tiles:insertDefinition>
> </s:elseif>
> <s:else>
> <tiles:insertDefinition name="editor.${cur.type}.w"/>
> <tiles:putAttribute name="value" expression="${cur.value}"/>
> </tiles:insertDefinition>
>
> </s:else>
> </s:iterator>
> </ken:>
>
> 2. If you feel like optimizing it... the above code looks up the getters
> and setters every time the view is rendered. I guess you're looking up
> other things, too (like validation conditions). But those things depend
> only on the class of the entity being edited, so it could be looked up
> beforehand, at startup time or at compile time.
>
Well I'm looking to use these tags with Struts2, which has a good
validation system... once the content is prepared and sent to the view it
should only be about rendering.
Then the code could look like:
> <tiles:insertDefinition name="form.${model.class}">
> <tiles:putAttribute name="value" expression="${model}" />
> </tiles:insertDefinition>
>
> with
> <<<tiles.xml>>>
> <definition name="abstractform" template="jsp-with-iterator-**
> over-editor.jsp">
> </definition>
> <definition name="form.user" extends="abstractform">
> <put-list-attribute name="get">
> <add-attribute value="login"/>
> <add-attribute value="firstName"/>
> <add-attribute value="lastName"/>
> </put-list-attribute>
> <put-list-attribute name="set">
> <add-attribute value="firstName"/>
> <add-attribute value="lastName"/>
> </put-list-attribute>
> ...
> </definition>
>
> Generating the "form.${class}" definitions could be done at startup time
> with a custom DefinitionFactory (actually a wrapper) or at compile time
> with an annotation processor (if you're using java 6).
>
I don't know much about tiles internals but I want to learn... I definitely
want this functionality at run time as I would like that editor feature I
mentioned to let definitions be altered at run time.
>
> 3. The JS/css part is actually more difficult. There is no way a single
> tag can generate content in both <head> and <body> sections, so you would
> need at least another <tiles:insert> tag, or possibly you could use a tiles
> definition to generate js/css instead of html (although I'd advise using
> freemarker or velocity for that, since JSP can be painful with anything not
> XML).
> But what I would do is simply create a JS and a CSS file that deals with
> all possible cases based on a CSS class. That would work the same for CSS
> and jQuery, and would be cacheable by the browser.
>
That sounds good... but I am envisioning users being able to define their
own templates. What you are saying could still very well work... I simply
create a unique JS file for each user and fold all their JS into it, same
for CSS. But I'm not sure... it wasn't what I was first thinking of...
Here is where my Tiles Ignorance is going to get high... I could test this,
but does tiles render each JSP separately and then include the content...
or does it merge the tiles all into one big JSP and then render the
content? I would much prefer the first... I've see the "preparer"
attribute for definition tags, but what I need is during... so if each tile
where rendered independently in a determinable sequence (order of
appearance by default) then assembled into a final template after the fact,
it would be easy to do what I wanted. The "body" tile in my case would
render first, the tags in the body would just push CSS and JS resources
(strings for paths) into a Set available to the request (well scoped the
struts2 action). The "head" tile would render later and so everything would
work. Can something like this be done?
--- I'm looking for answers to the above, the following is just musing...
but it might give you an idea of what I want to do ---
Further wishful thinking... If tiles could render piece wise it would be
very interesting if the progress of this rendering could be maintained
someplace plublic. Of personal use would be in an OGNL value stack, where
the main template would be called "#tiles" and be available within all the
templates. If each template would have its attributes accessible as a
LinkedHashMap, then it would be trivial for run time composition (in
conjunction with a template object factory). Also if a tiles definition
could have a "multiple" on a per attribute basis and internally represent
such multiple attributes as collections... then when the final view is
rendered, iteration would take place where multiples of the same attribute
definition has been set (including multiple inclusions of a template).
This would only be useful with runtime manipulation.
The nice thing is all the thinking can still be with xml "templates" as the
base conceptual unit (well they don't need to be constructed with xml)...
So I think the tiles framework is in a better position to incorporate
decoration type features due to its paradigm than say sitemesh is able to
swallow up tiles like features. With the ability to do these little things
it would make tiles very attractive. It could quite easily make quite
powerful tags.
> Hope this helps,
> Nick.
>
