Dear all,
In a generated JSF artifact openEHR-EHR-EVALUATION.SOAP_Assessment_aspect.v1draft.xhtml
The inputText is bound to a ManagedBean ‘archetypeBinder’ as seen below:
But ‘archetypeBinder’ is not declared in faces-config.xml
faces-config.xml
Hi,
It appears somehow I thought I was a member of this group, and apparently I
was not! So sorry for the late answer, I hope it still helps
The archetypeBinder is not a bean, it is handled by the CustomResolver class
in Opereffa JSF project, which extends JSF's binding mechanism.
In case you are interested, I can explain the reason for this implementation
choice. Just so you know, Opereffa is going under a huge refactoring, with
JSF getting out of the picture.
Kind regards
Seref
vanna wrote:
Dear Seref,
That is very kind of you.
I wonder why JSF is getting out of the picture.
That would mean, archetypeBinder CustomResolver will also be out?
Regards,
Kruy Vanna
Graduate School of Global Information and Telecommunication Studies,
Waseda University
Hi Kruy,
Good to see you have not given up 
When I choose JSF as the UI layer I chose it because it was a well known technology, with open source implementations and it had lots of tooling around it (again free). It had its limits though. Its main mechanism of connecting view (the browser) to models (the java objects) is via http posts. This object binding relies on http posts carrying data, and as UI requirements get more and more complex, I end up spending hours trying to mimic http posts just to get data from the UI to Opereffa’s wrappers. Also jsf on its own creates simply http forms, which lack capable UI functionality. that is why I used DOJO with JSF. DOJO gave me more capable widgets that can live in the browser, and perform complex UI tasks, like displaying tabs, allowing drag and drop, collapsing panes etc.
But when it comes to getting data from the browser to wrappers, the underlying mechanism is http post, and not a simple http post either, I have to mimic the exact way JSF uses http protocol, including viewstate keys etc. If you want to handle things like alternative values for a field (3 different options for s single field), or slots, or complex UI functionality (check out MS CUI), it becomes a nightmare to provide this connectivity. Take a look at the snomed ct bindings in the terminology bound form, for another example.
If you end up spending 80% of your time wrestling with the chosen technology, it means you are using the wrong tool for the job, and as people started asking for more UI features, I realized that JSF simply would not cut it, mostly because of its (kinda) naive assumption of forms connected to objects. its limitations made me invent solutions, still staying within its boundaries, like customresolver etc, but it only makes sense till you reach a certain point.
Also, people are asking for other UI technologies, so I’ve decided to take JSF out of the picture and use a web services based communication channel. At the moment, a version of Opereffa is under heavy development which uses REST based web services (for reasons that would take another post), with DOJO only UI widgets.
This model offers the flexibility that we’ll need to provide all the capability openEHR offers, and it allows multiple end points, not only DOJO. Please let me know if you have further questions.
Kind regards
Seref
2009/12/14 Vanna <kruyvanna@gmail.com>