Design with JavaBeans or not (was Re: [stringtemplate-interest] quick question)

[Andrew Goodnough]

>>> On Wed, May 10, 2006 at  6:40 pm, in message
<9C394E6A-BEBA-4585-A024-D6F330E6F907 at dolphin-services.de>, Kay Roepke
<kroepke at dolphin-services.de> wrote: 

> On 10. May 2006, at 23:18 Uhr, David Moshal wrote:
> 
>> thanks Ter, actually, it's not quite fixed (though in the example  
>> it is).
>> What I really need to do is for the model to tell the view how many 

>> rows to
>> create, ie:
>>
>> <% for (int i=0; i< rowCount: i++) { %>
>>
>>  <tr> <td> <%=i%> </td></tr>
>>
>> <% } %>
>>
>> where the model passes in "rowCount".
> 
> Well, in my book I would make the controller(!) decide how the view 

> should display things like paging and supply it with the necessary
> datastructures.  It should be the model and the view that ideally are
 
> reusable -  the controller mostly isn't. Thus to implement paging,
> there shouldn't be a need for the view to know about it.
> I'd have one template that says how to render a single element, a  
> list of elements (say in a row), and the paging part of the list  
> (current page,
> total number of pages, etc.). They I'd have the controller to sort  
> out pagination and the number of elements in a list/row and have it 

> prepare
> the necessary datastructures.
> No need for any expressions in the view. Clean model, clean code,  
> messy controller. That's what you mostly end up with in the MVC  
> paradigm. Of course
> there are ways to get a little structure into the controller part,  
> but in my experience it will always stay glue code -  it has to know 

> about both the
> model and the view.

Kay's nice explanation got me thinking again about whether I've built
too much into my template by using JavaBeans.  My Java controller builds
up a complex JavaBean with multiple lists, accessors, etc, a full object
hierarchy.  I pass this object into the main template and each
successive template call unravels the object to render it.  The problem
(if there is one) is that these templates only work with the JavaBean
that they're designed for.  For instance, a template which accepts an
Sample object assumes that the sample objects has certain attributes and
operations.  I can't reuse the template out of the context of having a
Sample object already created by the controller and ready to go.  Would
it be better to "unravel" the Sample object in the Java code, setting
string attributes into the template in order to make the template more
generic?  My argument against this so far has been that in order for
anyone to use the template, they need to provide to the template (in
some form) all the information that the Sample object provides to the
template now, so if they didn't use the Sample object and it's internal
logic/methods to build up the information, they would have to duplicate
what the Sample object does somehow - because the template won't work
without it.  All this is fine and works great, I just have a sneaking
suspicion from reading the posts that I'm using the JavaBean feature of
ST more than anyone else.  It could be just my application is different
(generating database-independent SQL to promote a database schema to
support a new software version).

Andy