hello Paul,
Paul Miniato wrote:
Hi Chiba developers,
Once again, thanks for a great product. We really enjoy
working with
it, and with the Chiba team.
thanks. i can give this back - your input is really constructive.
I notice that you are eliminating the chiba:data/@chiba:name
attribute and its associated ChibaContext.getExternalName().
While I can't fault your getting rid of the "obscurity mapping"
for parameter names, and have no quarrel with the new
philosophy, I'd ask
that you consider re-enstating a simpler version of
getExternalName()
-- i.e. one that just tacks the prefix onto the id?
For your own XSLT, this might make things a little cleaner in
that information about the prefix isn't hardcoded into the XSLT.
But it will also help us make the transition to 0.9.6. In
addition, it will
give us and others the flexibility to implement a different
parameter
mapping for other functional reasons besides "security by
obscurity". yep. hardcoding it in the stylesheet was the first step
to get rid of the unliked method. in the next step i'd like to
replace this by setting params to the stylesheet which are fed by
the configured prefixes.
ok, i understand that there might be reasons for wanting such a
mechanism but felt that it shouldn't be handled in the core of
Chiba. that was the main reason for removing the current
implementation - it simply grabbed to deep into the core of Chiba
to feel right. we try to clean up the interfaces and stabilize
them. but i feel a bit guilty cause i should have discussed this
on the list first.
i just thought there should be other ways of doing a name mapping
'from outside' e.g. by some servlet-filtering. but i'm not that
sure if that is possible or convenient for you in this situation.
By way of background, I'll describe a little about how our use of
Chiba has evolved during the development phase of our project,
which is now approaching its consolidation phase.
1.) The XForms we are using are machine-generated to follow the
paradigm that we decided to use for this project. This means
that there are certain structural rules that apply, beyond the
XForms specification. We call this our XForms "model" -- not to
be confused
with the model element in XForms. This has implications for item
2.
2.) We had always intended to implement our own XSLT for
presentation and started work on this quite a while ago. We have
developed one this is very much tuned to our XForms model. For
performance and other reasons, it is only designed to handle
XForms structures which are encountered within our XForms model.
Our original XSLT was only very loosely based on the html4.xsl
that came with Chiba 0.9.3, and it has since been almost
completely rewritten.
3.) We later realized that we wanted to do some matching
Schema-HTML
parameter transforms in the XSLT and the ServletAdapter
(previously WebAdapter), and also found out that the
ServletAdapter could not be extended in all the necessary ways.
At the same time, we decided we needed our own Servlet that was
quite different from the demo ChibaServlet that comes with the
release. (One reason was
our desire
to embed the Chiba forms in Struts Tiles, although we are also
considering SiteMesh.) So, we split off all of this
functionality from ServletAdapter and ChibaServlet as of Chiba
0.9.4. At this point, we are still committed to keeping the "off
the shelf" ChibaBean.
would be nice to hear some day what would have been necessary for
the extension to be possible. although we consider the
ServletAdapter 'only' as a reference implementation we surely like
to clean it up so it may be a valuable starting point for project
like yours.
In order to handle our types of human-readable date formats in a
simple manner, while not waiting for full localization and
handling of XML Schema, we ended up using a parameter name
mangling algorithm in our ex-0.9.4 variant of getExternalName().
Thus, the continued existence of getExternalName() and its effect
on chiba:data/@chiba:name would make our lives a lot easier. In
addition, I have to expect that other ChibaBean users will find
similar uses for name-mangling in ChibaContext, even if the
default mangling is direct use of the ID in the name.
ok, i heard your request. just give us some time to think about. i
still hope we'll find some more elegant solution than to call this
method form DataElement directly (which i feel is really ugly).
Hence our request to consider reenstating @chiba:name using
getExternalName(), or some similar mechanism we can implement or
override with our own mangling.
4.) Once our own development has stabilized, we are hoping to be
able to contribute some of the Servlet/Adapter/XSLT
components we are
using in our own environment, in case some of them prove useful
to other ChibaBean consumers. However, we suspect there will be
some other of our components which are just too special purpose
to be of much value to the community. At this time we may also
be able to write a longer report on our experiences with Chiba.
PS. At the moment, we have tried to use the 0.9.5 ChibaBean in
our ex-0.9.4 ChibaServlet/ServletAdapter, and found it did not
just "plug
and play", even after we got it to compile. We're just started
to investigate the source of this, and will update you with the
issues we find to be critical. We're eager to move our
environment to 0.9.5
because once again, the Chiba team has resolved a number of our
critical issues.
i'm impatiently waiting for your input. not that i want to repeat
myself but the goal is to fix the interfaces so future versions
really behave 'plug n play'. any suggestions in this direction will
be appreciated.
Joern
Thanks, Paul
Paul Miniato, Architect Standard Forms Project
http://ecommerce.cucbc.com
------------------------------------------------------- This
SF.Net email is sponsored by: IBM Linux Tutorials Free Linux
tutorial presented by Daniel Robbins, President and CEO of GenToo
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
_______________________________________________ Chiba-developer
mailing list Chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/chiba-developer
