On 09/05/2007, at 6:06 AM, Mike Schrag wrote:
> Yeah I think that's what he's saying ... Anyone have any
> suggestions? The problem is that if you want an outline view and
> completion on HTML tags, etc, we need to parse your document like
> an html/xml file. But it's a funky thing, because really WO
> templates aren't valid xml or html documents. In reality, WO is
> projection on top of your HTML or XML. This means it possible to
> construct all manner of invalid documents because all that really
> matters is that the final document is valid come rendering time.
>
> I was contemplating adding support for an additional flag in a
> webobject tag so that you can maybe do <webobject name =
> "Something" validate = "false"> and the contents of the tag will be
> treated like a cdata to the parser rather than html structure?
Your solution would work in this case, but probably won't for plenty
of others, this wouldn't have worked in my case without some
refactoring.
After thinking about it for probably not long enough, another
approach that would probably work better, might be to handle
conditional tags slightly differently to other tags. This being that
the conditional wo tags themselves only get validated against the WOD
file, and never as HTML, you could then have one of two possible
alternatives for deciding when to include the contents.
1) something like you suggested, "validate=true" where the
encapsulated code block would be included or excluded from the parser
based on this flag. (but without the surrounding wo tags). This
allows the developer to define a default, hopefully valid document
that will get parsed. The downside to this approach is that there are
parts of the document that would never get validated.
2) a more powerful but potentially more difficult to implement
solution would be to leverage the same inline binding syntax provided
by WOOgnl to have a condition="blah" property (and most probably
negate="true/false") to identify conditional tags, and then have an
entry (or a comment) in the wod file (or wherever is most suitable)
where you define the default boolean values for the condition
expressions used in the template. The appropriate conditional blocks
would then get included or excluded based on these defaults.
eg:
_validation_defaults: WOLips {
blah: true;
foo: false;
bar: true;
"$person.isAdmin": true; // Not sure about that one (from mikes
WOTips example)
}
or
myConditional: WOConditional {
condition = blah; //true
}
It would then be relatively easy for a developer to go in and change
these default values so that they can have wolips revalidate the
document with various conditional results applied. One upside to this
is that if you already use WOOgnl inline bindings you probably
already have these in your template, and if you don't WO will just
ignore them anyway.
Assuming this was remotely possibly you could extend this idea one
step further to have the concept of a validation "profile" where a
different conditional definition would be used based on the profile
name, perhaps by looking for '_profile_validation_defaults' instead.
Then you just need a way to tell WOLips which profile it should use
to validate the document.
I'm not sure if the defaults should best be defined in the HTML or
the WOD like above or somewhere else completely. It all depends on
whether having to parse the WOD file in order to parse the HTML file
is a big issue or not.
Anyway, that's my rambling for this morning.
> ms
>
> On May 8, 2007, at 3:19 PM, Sebastien Sahuc wrote:
>
>> Q,
>>
>> Is that what you are referring to ? I would need to use the
>> WOGenericContainer, but can't use the WOOgnl expr since we're
>> still stuck we WO 5.2 and Wonder 2.0
>>
>> <pastedGraphic.png>
>>
>>
>> Sebastien
>>
>> On May 8, 2007, at 8:11 AM, Q wrote:
>>
>>>
>>> One thing I have encountered with the new HTML parser is that it
>>> doesn't like woconditional blocks if you open a tag within the
>>> condition and close it outside. (think if/else). I was doing
>>> this in a few places and it was having kittens about it. I have
>>> now refactored the markup to use a WOGenericContainer and WOOgnl
>>> expressions to do the conditional handling instead. This makes
>>> the HTML cleaner, and it parses fine too.
>>>
>>> On 09/05/2007, at 12:46 AM, Mike Schrag wrote:
>>>
>>>> I suspect it means there is an unclosed tag inside that is
>>>> tripping it up ... What build are you using? These validations
>>>> have gone through several iterations, so maybe you have an older
>>>> build.
>>>>
>>>> Basically I'm parsing templates with a funky crazy xml parser
>>>> that tries to recover from horribly broken xml, but once you
>>>> have a malformed document, it becomes a big guessing game to try
>>>> and give you an error that makes sense because no matter what
>>>> rule you pick, you will break some other scenario.
>>>>
>>>> If you don't see the problem after updating, please email me the
>>>> html file so I can add it to my test cases.
>>>>
>>>> ms
>>>>
>>>> On May 8, 2007, at 10:34 AM, John Huss wrote:
>>>>
>>>>> In my page I have:
>>>>>
>>>>> <body onload="document.form.user.focus();">
>>>>> .
>>>>> .
>>>>> .
>>>>> </body>
>>>>>
>>>>> The problems view says: "<body> start tag is not found."
>>>>>
>>>>> Is there a way to fix that?
>>>>>
>>>>> Thanks,
>>>>> John
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Seeya...Q
>>>
>>> Quinton Dolan - qdola..mail.com
>>> Gold Coast, QLD, Australia
>>> Ph: +61 419 729 806
>>>
>>>
>>
>> Sébastien
>>
>> -- sebastie..ahuc.net / (415) 358 6969
>>
>> Do you gizmo ?
>>
>>
>>
>
-- Seeya...QQuinton Dolan - qdola..mail.com Gold Coast, QLD, Australia Ph: +61 419 729 806
This archive was generated by hypermail 2.0.0 : Tue May 08 2007 - 21:30:46 EDT