Re: Fixing the XML wrapper regarding the existence ops - Was: Handling missing node values with NodeModel

Tuesday, June 21, 2011, 8:32:19 PM, Tom Fennelly wrote:

> Well... it did "work" perfectly, but I can see that it might not be
> what you'd like.  I was just happy to get something that got me going again for now
>
> On 21/06/2011 18:28, Daniel Dekany wrote:
>>    - myXmlNode.foo means "I want that *single* node". If there are no
>>      matches, that's a undefined variable error, thus `!`, `??` etc.
>>      works as expected. If there are multiple marching nodes, that's a
>>      TemplateModelException, that can't be suppressed (except with
>>      #attempt, of course).
>
> I'm sure this my come across as ignorance on my part (and maybe it
> is ), but as a user... I find exceptions in situations like this
> (multiple matching nodes) to be a bit painful/pickie. I can see
> (from a purest pov) how an exception may be the "right" thing to do
> in order to force the template author to fix the issue, but I
> sometimes find that the exceptions produced are not always so easy
> to follow for someone that just occasionally uses FreeMarker i.e.
> it's not always obvious what I need to do as a user to get from an
> error like "Expecting a string, date or number here, Expression
> .vars["com.acme.Booking"]["checkIn"] is instead a
> freemarker.ext.dom.NodeListModel" to something that works (same with
> the treatment of nulls).

The root of the problem is that the data-model (the "parent" variable)
doesn't help to create a better error message, and it's the parent
variable who has the knowledge to create a more meaningful error
message, after all it knows what it wraps (like XML). This is a
problem elsewhere as well. This is technically solvable by extending
the "architecture" of FreeMarker... However where I above say that
multiple matches would cause an exception, since that's raised
directly by the XML wrapper, it can have a user-friendly error message
even with the current architecture.

> I suppose I'm saying... if you're going to employ a very strict
> policy in terms of what's accepted (resulting in frequent templating
> exceptions that need to be fixed) then the errors need to be really
> really good and need to help you get back on the road quickly.

I firmly believe that even an error with a difficult error message is
better than an error that is suppressed... I wish I get more error
messages from other tools instead of silently breaking stuff. But of
course error message quality is important, and it's lacking in FM.

> I hope that doesn't come across as being critical...

(It's OK to be critical around here.)

> FreeMarker is awesome and I know that this type of thing is always a
> huge challenge for every framework !!
>>    - myXmlNode.foo$ means "I want the list of the matching nodes".
>>      This would always return a sequence, even if 0 long. Why "$"?
>>      It could be read as the "S" of the plural form, "foos". (I think
>>      this was originally the idea of Jonathan.) The drawback is of
>>      course that this way we deviate from XPath, so XPath expression
>>      couldn't be written as myXmlNode["foo//bar"] and like. Instead,
>>      they had to be written as myXmlNode("foo//bar") maybe.
> Sounds good. Might another syntax for saying "I want a list" be
> something like "myXmlNode.foo[]".

What I have recommended is solved purely on the ObjectWrapper level.
"foo$" is a valid variable reference, and it's up to the XML wrapper
to interpret it. foo[] isn't a valid variable reference, at the
moment... while technically it could be, it doesn't look like one. It
looks like an operator after "foo".

>> Neither of these are strictly backward-compatible, but since we can
>> have multiple wrapper instances and instances can be configured or of
>> different classes, that's manageable.
>
>> Another thing... I find it scary that we depend on internal API-s to
>> do XPath with Xerces. If they still haven't added the required API-s
>> as public, well... in the new wrapper we should just require Jaxen.
>> Unless, there are performance problems with that or like... anybody is
>> aware of such issues?
>
> I know that Jaxen is nice enough to use from an API standpoint...
> not sure about the performance because where I used it I eliminated
> that as a risk - Jaxen was really just used to parse the XPath
> expressions... was not used for evaluating.

-- 
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev