Stefano Mazzocchi a écrit > > The problem is to separate concerns. We aim to have a template language > that we can give to graphic designers and therefore they will be given > the page and the variables that contain the dynamic data they need to > present. No other information is required for them to accomplish their > task. > > This is IoC at the template level and all the information on "how to > populate the context" is somewhere else (at the 'controller' level). > > By placing even a single <sql:query>select * from users</sql:query> in > the template you are breaking this isolation because now template > designers need to know the structure of the database (and they don't!), > so this resorts in having two people having to maintain the same page. >
This is exactly what i'm talking about. I never wanted to put such "low level" things inside the template directly. I was just talking about the possibility for a developper to add some tags (macros or other) precisely for his designers so they don't have to know the database structure. For example a <my:UserProfile /> (or even better <my:get from="userprofile" what="telephone"/>) is sufficient to retrieve the user profile from the xmldatabase (designers obviously don't know where the data come from). The job is done in an included jx:macro, or even better in a java component so i can reuse this code in flow (if it can serve somehow for some kind of logic inside the pages flow). I don't need flow here, it's a pure template (SoC). In fact, for doing this i would have 3 solutions: 1) access the servicemanager and write some (ugly) xml jx code. With the help of various components, access the data, return a dom or a string. For not disapointing my designers, encapsulate all that ugly stuff in a jx:macro in a separate file. Not really good but better than nothing. Not possible without blackmagic. I have no access to servicemanager under jx. 2) extend jx and suply my own tags, exactly the same solution as jx:macros but in java. As an avalon component my tag library would have full access to the servicemanager. I could reuse some part of my component under flow if necessary. Better than 1) but not possible too: there's no extension API to JX. 3) use the sitemap to pass parameters and use the rich input module library. IMO the the best solution, but impossible for a real use case. Because i can only pass strings, i need to pass hundreds of parameters where a single dom would have suffice. So this let me making several observations from the actual design: 1) JX and Flow are so tied that you can pass object from one to another. The sitemap, which play a side role (pipeline->Flow, Flow->pipeline) and central role (Flow SendPage->pipeline->JXTG) is curiously excluded from the conversation (it don't speak the same language: it can only pass strings as parameters). 2) but JX and Flow are not so well tied (from a user point of view), as OM between JX and Flow are completely different (perhaps more homogene with jxtg 2.0 but not exactly the same as i could understand). I can access to servicemanager from flow but not from JX. 3) CForm "extend" jx by the mean of some macros (tags with their own namespace), but apparently we (cocoon users) are not allowed to do that (no extension API) even if cforms macros have been said to be really convenient (ie other things than forms could be implemented and provide the same convenience without breaking SoC). We are not allowed either to mention the word "taglib" even if it's one ;-) Without a clean API, sylvain had to do some blackmagic inside macros and added an xml consumer in the jx $cocoon map. What happen to the beloved SoC if i can screw up the sax flow directly from jxtg (the designer land tool) ? Ok i'm joking a little, but i Just wanted to show that a taglib (please don't flame me :-), could be usefull here and would help to not break SoC if your will is to allow extensions like cforms in jx. Conclusion. If i could pass other things than strings in the sitemap you could remove (deprecate ;-) the $session, $cocoon and all that stuff from jx and keep it minimal (Just keep variables). I see explicitly from the sitemap what i use in my template or in my flow. Define a tag architecture so that blocks like forms can plug cleany into the sax generation of jx. Otherwise, please (poor user request :-), keep the OM homogeneous between JX and Flow and let me separate my concerns by accessing the servicemanager. > So, normally, this ends up having a pipeline, one person manages the > generator the other manages the transformer, but at this point, the > contract between the two gets bigger than a simple template context. > We are all agree. WAIMS (where am i missing something ? :-) WDYT ?
