Re: chiba:data/@chiba:name, ChibaContext.getExternalName(), and the "Big Picture"

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

-------------------------------------------------------
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_id=1470&alloc_id=3638&op=click