Antonio Gallardo wrote:
Leszek Gawron dijo:
I have implemented only a few small projects using jxtg and found some
live examples of these limitations:
1. you cannot parse string from your model as xml, had do use session
hacks to do that ( put flowscript function into session, use it via
macro in jxtg):
function xmlProducer( value, consumer ) {}
cocoon.session.setAttribute( "xmlProducer", xmlProducer );
in jxtg you do:
${cocoon.session.xmlFormatter( mydomainobject.property,
cocoon.consumer )}
or create a macro to hide this awful syntax.
We also use session and this kind of stuff is prepared on the flow script
or a helper java class. As I told before JXG just read data. It was not
intended to be forced this way. Bussiness model stuff must be separated.
a template language user should not be forced to create helper classes
and if he/she needs a particular specific functionality it should be
plugged into and not used explicitly.
2. same for wiki syntax
Don't know. I never used something like that. We are more DB oriented
programmers.
Some of my entities have "description" property which I allow users to
will in with wiki markup so it is nicely rendered on the page.
3. I had to write a special class to create links that hold all current
request parameters apart from selected ones (i.e. to reload the same
page under different locale).
then use it like <a href="${Packages.com.mobilebox.utils.
LinkFormatter.getLinkWithAllReqParamsExcept(
'locale'}&locale=en">Switch to english</a>
Flowscript again is good for that. JXG is not the right tool for that.
Flowscript is a controller, controller should not perform data
formatting. it is view specific functionality. I should be able to
switch jxtemplate to another one simply changing the view uri in
cocoon.sendPage. If that forces me to refine my controller although the
new view uses the same data - it is SoC break.
4. There is no jx:attribute functionality so if you want to insert
attributes conditionally you have to duplicate the WHOLE node (which
might be huge)
Flow script job again.
Not true. View is the one to decide if a piece of data should be
rendered as tag or attribute. You use it this way because you have to
overcome JXTG's lack of that feature.
you are not able to plug any of these "extensions" (hacks should be
written) to view once and for all so you end up setting your session
attribute for every view that might use it and importing a macros file
in the same jx template. FreeMarker allows to configure so called
"shared variables" that provide additional functionality. You could
subclass a FreeMarkerGenerator to register any of your additional
functionality without performing such ugly hacks.
All this processing is VIEW specific only. I should not be forced to
create another bizData data representation for every view I come to
implement. This breaks SoC as I might want to create more than one view
of the same data. If I followed your proposal I would have to end up
implementing several bizData representations. This is half a step ahead
from implementing a pure xml generator - try to do that for every view
in your project.In JXTG you can break SoC whereever you like. Browse
cocoon examples and mailing list for constructs like:
<jx:set var="ignore" value="${performSomeOperationsHere}"/>
worse :
<jx:set var="ignore"
value="${Packages.com.mycompany.ClassThatWillMessThingsUp.doIt()}"/>
I never needed something like that and we present sometimes the data in
diferents formats and order. Even sometimes we need to skip some pages
based on the user input, a simple <jx:if> is enough to make the job done:
<jx:if test="${ignore == 'false'}">
...
</jx:if>
The ignore variable is part of the bizdata that comes from the flowscript.
I know the line between what is VIEW and what is MODEL is very thin. But
we prefer to let the MODEL decide what the user will see. For us JXG is a
template generator, nothing more nor less.
I am not talking about the need. I also never needed this. But if you
exposed your jx template to be edited by user online he/she could inject
such code and bring your server down. I was amazed of jroller
functionality that allows user to access the template of every part of
his/her blog template to be edited. One has a library of macros to
access blog data model. It's completely up to you how you present it.
Noone needs to alter the data model (which should be entities straight
from database not altered at all) if user prepares a new view for his data.
I think velocity stoped to be developed (as was posted in the provided
link) because it stoped to be interesting. People found another ways to
make the job done. I think mainly because XML was on the scene. But
velocity was a very nice language at the time, trying to provide HTML
dynamic building features. Currently, I saw both (velocity and
freemaker)
as some kind of JSP, ASP, PHP, etc. I think we (cocoon) are beyond this
technologies while we still use them for some special cases. Note I am
not
telling they are useless.
There is one big difference between jsp, asp, php and the templating
languages: templating languages does not allow injecting program code
into template. Velocity is far closer to JXTG than to XSP, JSP
We are not "beyond" as we have no powerful templating language. JXTG
offers 10% of functionality of FreeMarker or Velocity.
The point is we are moving away of this kind of things. This is what I
think. We try to keep clean sources. A mess of VIEW+MODEL is not good and
that is what we got using velocity...
how do you mess your model and view with velocity? I think it's even
kept cleaner in Velocity as you cannot execute external code with such
ease as in JXTG. Even the opposite: right now you are messing your data
model with presentation information. That is what you said yourself.
Well, as I told you before, if you feel that FreeMaker feel the gap to
you, it is OK. Please create the generator and show us. Really as I told
before, I am not against it. I am +1 to see FreeMaker in action.
I will create a trivial and stupid implementation in a few days - just
to evaluate freemarker features. We'll see.
--
Leszek Gawron [EMAIL PROTECTED]
