On 13.07.2007 10:31, Grzegorz Kossakowski wrote:
In a state full scenario we are keeping the form object in e.g. a
session, so the form template generator could store the associations
between property paths and formating variants in the form object as
well.
Doesn't that tie both CForms and CTemplate together?
My understanding is that this approach ties CForms to EL and CTemplate
to EL so EL functionality becomes a bridge for two way communication.
This is indeed more exact. I considered EL being part of CTemplate :-)
I also wonder how you are going to use CForms without CTemplate? You
must use some template mechanism to produce data representing form and
its state.
FormsTransformer? It has a template approach as well [1], but no EL at all.
Actually I'm not very keen on any templating approach at all. I don't
like to first provide data to some template context and second retrieve
it from there in the template. IMO it's much better to have a complete
push approach and only encroach if it is necessary (like XSLT
templates). (My diploma thesis was about this btw.) A possible
implementation for this is to convert the form model into an XML
representation and let a quite generic XSLT do the rest. With this
approach no EL come into play. This also means there is a separate
object-to-string step.
In a stateless scenario, we could instead store the assoications in
the form page.
IMO it should always work this way, not like the above one for
stateful form-processing.
This would make whole processing easier to follow, wouldn't it?
Difference should not be that big since it's more an implementation
detail than something that should concern the user. My main reasoning
was the decoupling of EL and CForms.
And actually we are back to the Spring way using the path, aren't we?
There is only the minor difference of using the full path vs. the
anchor. The anchor adds additional flexibility since it can be
specified in contrary to the generated path.
My impression is that there is a more serious difference between the
concepts. While using Daniel's approach you attach converter to the
certain path by choosing its variant when you actually pull the data. It
doesn't matter if you pull it in form model or template.
Spring approach is about attaching everything in advance.
That's true. It's the controller that decides which converters get
applied, not the view.
The "minor difference" I talked about was from the registry POV.
Something is just asking for a converter, the only difference is the
string which is used for retrieving the converter then.
Then it turns out that Daniel's proposal is about registering several
converters for every possible path and use variant to choose one from
the list (if default is not satisfying). Since, it's all about
registering for every possible path (assuming that there is suitable
converter for each object) and registering more than one converter it's
conceptually different from Spring's approach.
Hmm, not really. Even with the current default implementation you can
register multiple converters per path differing in the type. You just
add another criteria. What's different is the more complex understanding
of "path" since you might include the variant in it. Seems to be only a
matter of registry implementation how it stores and finds converters.
I hope that paragraph didn't confuse things even more...
I needed to read it twice but I think I got the message :-)
So how far are we from an overall agreement and Grek implementing this
for us ;-)
I would happy to do it, but I'd be very grateful if we come with strong
and detailed agreement.
I didn't want to put any pressure on you ;-) Just wondered what the open
issues are we still have.
Joerg
[1] http://cocoon.apache.org/2.1/userdocs/publishing/templating.html
