Leszek Gawron dijo: > Joerg Heinicke wrote: >> On 05.11.2004 11:19, Leszek Gawron wrote: >>> Still this is very inconvenient if the model is built for you i.e. >>> object graph built by hibernate. I would have to make controller >>> dependant on view view wants to show. Right now I just pass one entity >>> to view and do not care if view asks for entity fields, entity parent >>> fields, child fields, anything. If I have hibernate properly set up >>> the data will be retrieved only when needed. >> >> >> But the view is not reusable. > Now I get it why some cocooners have such a different opinion. I think > there are two worlds that cocoon covers: > - xml publishing, dynamic sites but with not that much business logic. > Here the most work is put into data aggregation and rendering. I think > your opinion represents this world. > - web applications, totally dynamic, a lot of business logic. Most work > is put into model and business logic. The controller is also > significantly more complex. View is the least sophisticated here. This > is my world :)
Yep. This is true. To me this exactly one of the most interesting parts of Cocoon. We like to see solutions that fit in both worlds. Often we find it ;-) This is one of the things why Cocoon rocks! > I am developing web applications. That is why the main concern for me is > the MODEL reusability. I do not care about the view reusability as > almost everything is modelled in html (For styling I use single > site2html.xsl which applies common styles, toolbar and menu). For apps I > seldom use aggregation and 99% views are JX generated. I think is posible to care a lot about the MODEL reusability and at the same time use rendering pipelines for various formats. In my case JXTG represent cca. 40-50 % of the views. > I've done a few publishing projects. I agreee with you but only on the > field of publishing projects where the rendering pipelines are huge and > usually you produce data in various formats (HTML, PDF, printable HTML). > >>> I have project that model have 5-6 depts in parent-child relationship >>> like: >>> contractor -> surveydefinition -> questioncategory -> >>> questiondefinition -> alertcategory -> alertdefinition. >>> >>> While displaying list of entities on any level I can choose to add >>> additional column with link to parent on any level and the only thing >>> I have to change is the template. Model remains the same. >> If the model changes the view has also to change. > What I try to emphasize: If the view changes the the model doesn't > necessarily have to change. I think this is correct and currently is working in this way or not? The SoC idea means both (model and view) are independents each other. > For web applications: > - the model is the first to be agreed upon/designed/implemented > - the model is the core of the application and most weight is shifted in > that direction > - the model is strongly typed, has a lot of constraints. Almost whole > model consists of POJOS. > - the model does not change much. If it does it's much bigger problem > than just updating the views because it involves a lot of business logic > to be changed. > > That is why I need my model (especially built by hibernate) to be clear > and reusable. Not the view. > > Also I need the rendering logic to be applied in the view and not > earlier. I need to be able to choose a convertor during view generation: > - I might want to show property value in plain text in one place (for > editing) and in the same view pretty printed below. > - I do not want all Integers < 0 to be rendered red. This is based on > the context. It is also inconvenient to put that info into the model as > there may be a lot of orthogonal views of the same data. The model would > have to support everyone. Yep. This is the idea. But we need to take care that there can be other rendering views too. >> You all seem to have >> only just one view in mind. What about having different views for >> different browsers or devices? While it might be easy for browsers by >> using XSLT and change here and there a bit, it's nearly impossible for >> different devices. Who takes control whether to show 5 widgets or 50? >> Using templates it's only possible by using different templates. And so >> if the model changes the different templates have also to change. And >> the templates are still not reusable! > Probably we need either 2 templating languages or a single one covering > both approaches. The later better. Or what about 1 tranformer for the views? >> Shall the view decide it? Even with renderers/converters this makes it >> being not reusable. As Terrence Parr wrote: The view should be reusable >> with a completely different model. The configuration must happen >> externally, i.e. neither in model nor in view. > This clearly makes the difference for web applications: The model should > be reusable with a completely different view :) Both statements share in common what I told above: I think is posible to care a lot about the MODEL reusability and at the same time use rendering pipelines for various formats. Best Regards, Antonio Gallardo
