Re: Access to BTemplate on request phase ?

Hi,

> Probably quite expansive, isn't it ?

Well, its O(n), which is not so bad. Lets say you made your application 
configurable using xml, the costs would be the same.

> In fact Hibernate uses Javabeans to persist objects.
> So I don't have hashmap at first, and I wrote a base class implementing
> generic access using reflection. For example, I do :
>
> myDataObject.getStringByKey(mytoken) and my data object bean returns his
> getKey() value.

Hmm. This still looks like a map to me - you simply don't call it map :) From 
what I understand from this, mytoken is a key that gets translated by you 
using reflection or whatever to query the underlying bean. Or do I miss 
something here?



> Now my problem is that I would like to let the "poweruser" change the
> layout of the screen, and choose the attributes she wants to have
> (some of them would be compulsory of course). My database will have
> quite a lot of fields for an entity, and not every user will use them
> all (but two users will use differents fields).
>
> So I could just stay with my current  application and BTempalte will do
> the rest. That's quite cool and flexible already.
>
> But say I have 50 fields in a (database) table, and the user only wants
> to use 10 of them (I don't know which one, only the consultants can
> tell, at runtime maybe :-)
> What would be cool would be, in the request phase, to know which fields
> are required, then to query only those fields (maybe also get hibernate
> to retrieve only those fields from the database) and only return a
> partial dataobject to the web tier (saving 40 objects instanciations for
> unused attributes, bandwith at serialization, and maybe database access).
>
> So this is my question : how do I get the required fields ? My first
> idea was to get it from BTemplate at the REQ phase, ... but as you said,
> this is not standard, and parsing the dom might make me loose all the
> time I gain by tayloring my request and dataobject...
>
> Is all this a little bit more clear ?
> What do you think of it ?

Ok, I think I got a better idea. Basically you want the html snipplet which 
queries the BTemplate double-use as configuration-file for the fields the 
user wants to display.

I've got some thoughts about this. First of all, you can simply do it - just 
create a BTemplate, and a special model I'll describe next, bind the view and 
render it. All this at request-time!

Now the special model simply gathers the keys it gets passed in the 
getItem()-call. So you'll end up with all the defined keys in your view. You 
can then use this to query your persistence-layer, and create a map 
(remember: getItem(String key) is also a map - its not in the same interface, 
but its basically equivalent). This map (or TemplateModel, if you prefer that 
name for the same thing :)) will be displayed by the very same html-snipplet.

If you are concerned about performance, you might want to extract the keys 
only when really neccessary, not always. But thats only a implementation 
detail.

However, I actually doubt you gain much from your whole approach (except from 
the customizable view, but thats of course "built-in", as you can always 
decide _not_ to display items in a template model). The thing is that from 
your own words I see that hibernate uses beans. Now unless hibernate doesn't 
use lazy-loading for single properties (which I strongly doubt), you will 
still fetch all the data from the db into the object. The only gain here is 
less html rendered. 

Where exactly do you think you'll end up in less data?

Regards,

Diez