Hello Robert,
Robert Simmons wrote:
Whatever we see as the long term goal should be done now. Once chiba gets
out there and 4000 people are using it, changing things massively liek this
will be impossible.
even after working for nearly 3 years with XForms now i really cannot
say what 'the long term goal' should be. surprising? not really if
you're taking into account that its a totally new (and exciting)
technology. when following some discussions on the xforms list you'll
see that there are a multitude of opinions what this goal might be and
how it can be reached.
of course, we have our vision of that, but IMO every single step on the
way must be taken to be sure to not loose direction.
having said this it may become clear that our plan reaches out only some
month into the future by now. at the moment we cannot hope to make
better than providing a good guess of what XForms may become and how its
used best.
and we must be prepared that things will change. i would be happy to
develop a reasonable good interface for Chiba and get it stable during
this year so that users are not affected by implementation changes (as
least as long as there are not feature additions).
the DOM question i've raised is such an implementation issue.
You say that a full DOM impl is much more work but im not sure why that is
the case. Granted Im no source expert yet but it seems to me that the
benefits might outweigh the cost. It might be a now or never thing.
i'm not a believer in 'now or never' things. in my experience these
decisions often reach out much too far into the future and do not take
the details into account - which will break your legs later after you've
invested much work and realizing that you've missed a small but
important point - happened to me already on this way ;)
IMHO a full DOM impl is out of reach and scope for the following reasons:
[1] not all of the features we need are reachable through DOM interfaces
currently. take schema validation as example: xerces as one of the most
advanced and complete impls does provide full DOM 2 but only
experimental DOM 3 support. this means we still have to use xerces
implementation classes for this purpose. - this will change maybe when
DOM 3 support is complete.
[2] our focus is to implement XForms not DOM - we just like to use DOM.
[3] implementing our own DOM without extending Xerces classes definitely
is more work: at least we need a DOMParser that builds a custom Document
and support Elements and Attributes. as you know these interface cannot
be called lean and would force us to re-implement things that are done
elsewhere. this will introduce new sources for bugs and doesn't really
brings us forward to our original goal.
in contrast my suggestion to annotate the xerces DOM with
set/getUserData limits our xerces dependency to only these two methods.
as soon as full DOM 3 is available we can change the calls and return to
parser-independence (although its unlikely that there's an alternative
to xerces then).
it also would still be possible to make Chiba work with another parser
but for the cost of extending the specific implementation and adding
similar get/setUserData methods. this shouldn't be too hard.
also, it's a lot easier to be done with our current code cause after
evaluation of the needed changes we encountered only a few places that
need real re-implementation of methods. most of it is pure refactoring
and can be applied quite quickly.
it might even work out that the 'annotated DOM' is in fact a better
model than a native DOM implementation cause it adheres to the 'prefer
delegation to extension' rule *and* it allows to reach our goal: to
remove an unneeded second hierarchy of objects (the initial intend).
i hope this helps understanding what the proposal intended and how we've
come to this conclusions.
Im also not sure why DOM would necessarily tie use to xerces. DOM is a W3C
standard and as long as we dont use anything Xerces specific, why couldnt
the USEr use his processor of choice?
see above. i really would like to hear about some alternative parser
that is capable of doing what we need.
best,
Joern
-- Robert
"joern turner" <joern.turner-S0/GAf8tV78@xxxxxxxxxxxxxxxx> wrote in message
news:3F552169.4030605-Dk7vmzu7AY7hvxM+mQhndA@xxxxxxxxxxxxxxxx
Hello *,
after rethinking the problem with the DOM, we (uli + me) discussed the
topic again and came up with a different solution:
it's clear to us now that there's no way but to use Xerces if we want a
full xforms implementation. main reasons currently are DOM events and
Schema validation.
Since we've made our hands dirty already (with using ElementNSImpl in
Instance) we can expand this even further by also using the xerces
specific setUserObject/getUserObject methods.
after first estimization implementing a full DOM is much more effort
than refactoring the existing code to couple DOM nodes with their
appropriate Chiba object. this also allows removal of the navigational
code in our existing classes and therefore reaches the same goal than
the full DOM impl. i call this approach 'annotated DOM' and i think it
even may bring advantage over extending DocumentImpl which ties us even
stronger (prefer associaten to extension) to xerces.
if anybody thinks this may be harmful please speak up. we're still open
for discussion.
joern
joern turner wrote:
hello,
a big step has been taken by refactoring the classes for 0.9 release but
further investigation of what still needs to be done lets me think about
a DOM implementation again.
this is not the first that this idea has been evaluated and of course
its an obvious option when reading the spec. by strictly taking the KISS
principle we always answered this question with no - until now.
now, quite a bit of the functionality of XForms has been implemented and
it seems that our approach of 'as little classes as needed for the job'
have nonetheless brough us in the region of a full object model instead
of some annotations to the DOM here and there.
to reach full support of the spec we'll need even more functions
normally found in a DOM parser so the option of rolling a custom object
model is like re-inventing the wheel.
Xerces is and will be for the foreseeable future our parser of choice
cause its the most complete (events, schema) implemenation available.
First experiments i've made with extending Xerces DocumentImpl are
promising.
again, this idea is not new or some great innovation but just a decision
to take about how to proceed with Chiba. i expect the following
advantages:
- many helper-structures now needed to associate aspects of XForms with
the DOM would vanish into void (code reduction).
- the event model is much easier to support and handle by extending from
core event-classes
- schema validation comes built-in
- clarity of implementation through close adherence to DOM model (no
intransparent indirections/wrappers and helper structures)
cause i take my job serious ;) i've studied the X-Smiles implementation
which is another open source java implementation but embedded in a
browser. it looks like a very good piece of work and they've already
done what i propose here.
maybe this only validates the correctness of this approach:
that we've come to same results. - and we've also decided earlier if
we've had the working group connection ;)
anyway i'd like to hear about your opinion about this. otherwise -
you've been warned ;)
joern
-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click
here:http://www.vmware.com/wl/offer/358/0
_______________________________________________
Chiba-developer mailing list
Chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/chiba-developer
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Chiba-developer mailing list
Chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/chiba-developer
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
| 
