Hi Flavio,
listas-gKsXbHVs43GLjhqoV9UUrw@xxxxxxxxxxxxxxxx wrote:
Hi Joern,
very interesting component. not sure if the same effect couldn't
be modelled with a repeat but if it's usefull for you why care?
When we see the screen repeat seems to be a possible way of doing
it, but although the component looks like a repeat, it behaves like
an itemset. Repeats are not made to select items from a list, but
to show and edit the repeated data. Maybe it could still be
simulated with a styled repeat and some actions, but writing a
custom component we can have more flexibility, simpler and more
intuitive markup. Even if it's not the only way to do it, it seems
to be the best.
if this fits your purpose best there should be no complaint and i see
your point.
did you think of using the official XForms way for extensions? e.g.
<xf:select ..>
<xf:extension>
do whatever you like here...
</xf:extension>
</xf:select>
this simply wraps your markup inside the extension element and still
provides standard conformance.
We discussed this, but I'm not sure we should use xforms:extension
element. The spec raises two relevant points on extending XForms,
MustUnderstand Module and Extension Module.
MustUnderstand is used to tag "critical foreign namespaced elements"
and Extension is used to "elements from any namespace other than the
XForms'". As I interpret it, I see a subtle conflict between the
goals of these two modules. I think we can mark any foreign element with
MustUnderstand without using Extension, as stated in the MustUnderstand
Module spec:
"Certain elements, such as extension or foreign namespaced elements"
"a single attribute that can be used on ANY element"
i've to agree again. the MustUnderstand method should be a valid option.
The Extension Module is more or less like MustUnderstand, but it does
not define any processing requirements for its contents. If putting
foreign elements inside Extension was necessary for standard
conformance, then MustUnderstand and Extension modules would be just
one, maybe the MustUnderstand attribute would be allowed only on a
extension element or one of its children.
yes.
sounds to me that your case is more compatible with MustUnderstand while
the extension element is by no means required here. the example given in
the spec also seems to imply that in case you'd like to extend the
behaviour of a XForms element you can use extension to hook into the
control and maybe extension should be reserved for this purpose.
From the spec, as long as XForms is concerned, we can put foreign
namespaced elements wherever we want. If it's not marked MustUnderstand,
and the processor does not recognize it, it must be ignored. On another
hand, Extension Module is not useful for XForms itself, but to avoid
conflicts with the host language. Inside Extension, a strict validator
would allow "unregulated content" and the XForms processor could use
the information in any arbitrary way (maybe even ignoring it). A real
violation of standard conformance would be to declare the component
in XForms namespace. This way, in our case we have no reason to
enclose the custom component inside a extension element, but as the
listing is the main data in the form we want to mark it with
MustUnderstand.
yes. i think this is a clean and absolutely valid approach and your
deductions are quite right.
Actually, we already have a proposal for implementing both the
custom element support and the MustUnderstand Module. In brief:
1) Create a class named CustomElementFactory.
2) Change the classes Container, Initializer, Config.
3) Add a new section to the configuration XML file.
Container class can receive a new method getCustomElementFactory(),
to return the CustomElementFactory. This method is like the existing
getElementFactory().
As the XFormsElementFactory is responsible for identifying and
creating XForms standard elements, CustomElementFactory identifies
and creates components which implement the custom elements declared
in the configuration XML file. This new factory can be placed inside
org.chiba.xml.xforms or in a new package.
CustomElementFactory basically has two public methods:
isCustomElement(Element) and createCustomElement(Element, Model).
The former method returns a XFormsElement, so the custom elements
will have to extend XFormsElement too. In this case, the Javadoc
for XFormsElement class will have to be changed to inform that
it's also the superclass for custom form components.
These methods are called from Initializer.initializeUIElements(...).
It will look like this:
//now gets both element factories
XFormsElementFactory xformsFactory =
container.getElementFactory();
CustomElementFactory customFactory =
container.getCustomElementFactory();
[...]
if (xformsFactory.isUIElement(elementImpl)) {
//here the code stay the same as today's
} else if(customFactory.isCustomElement(elementImpl)) {
//the custom elements are initialized here
}
The new configuration section shall be like this:
<custom-elements>
<element namespace="http://domain.com.br/our";
name="list"
class="br.com.domain.chibaext.List"/>
</custom-elements>
Config class will have a new method to read this section,
loadCustomElements(JXPathContext, String).
These are the changes needed to support custom element processing.
The support for MustUnderstand Module is implemented inside
isCustomElement(Element) method. This method first checks if there is
any custom elements. If there is no elements defined in the
configuration, it always return false so applications not use this
feature will feel no performance penalty. If there are custom elements
it proceeds to see if the current element matches one of them. If
there is a match, it returns true. If there is no match, it looks for
the mustUnderstand attribute. If this attribute is present, it means
that it's a foreign unrecognized element and a XFormsException is
thrown to report MustUnderstand verification failure.
great proposal! - think i'd done it along very similar lines. i find
nothing to object against this plan cause it's a clean extension that
does interfere with any other processing.
my +1 for this plan.
Joern
the xforms prefix in NamespaceCtx is only used in PreProcessor in
case no prefix was provided in the input document. so it's just a
default here and not used statically for all documents.
OK, I was just wondering why there is a constant with the *prefix*,
surely it's not up to the user to define the namespace URI, it's a
design requirement.
Best regards,
Flavio
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Chiba-developer mailing list
Chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/chiba-developer
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
|
