[arshadm]

Hi,

Thanks for that info, now I understand the problem. This is going to be tricky to navigate, but I am sure glad Vladimir brought it to my attention.

Regards.

[vladimir.kovalyuk]

In fact there should be the difference between handlers. The problem is that Facelets does not make difference how they look like in markup. They look similar. Instead of beeing concentrated on hi-level business task i have to distinguish them struggling with unexpected problem and think about all the internal details of Facelets. Needless to say it does not help the project to be released on time.

The same about JSF - some attributes are evaluated before or after the other attributes. For instance rendered and id.

[arshadm]

Yes. It really is very bad, I have to constantly keep in mind to ensure that the original view that was parsed and saved is appropriate for any postbacks.

Somebody really needs to get a handle on this. Maybe the view should not be saved, it should be parsed everytime or some variation thereof.

Regards.

[cjalmeida]

Despite JSF being allegedly less productive (which I disagree), is a standard and there's a good chance of it being up and running in five to ten years (the life span of an ERP).

Anyway, more important is the fact that an ERP is extremely data intensive, process based and requirements changes a hell lot. IMHO an ERP should leverage a BPM engine (like jBPM) and have a UI that is self generated. I really advise you to take a look at Metawidget (http://www.metawidget.org/) It's not so intrusive as a UI generator and can be used within JSF and Seam and integrated with JPA and Hibernate Validator.

Another must have is a contract based modules system. In short words it means you can replace your simple MRP scheduler with über JIT scheduler transparently to your sales, HR and other modules. Harder said then done, but can save you a lot of time latter.

I would recommend you checking out OpenERP (former TinyERP). It seems to me the best open source ERP in terms of architecture. Python-based but source is very readable and easy to extend.

Openbravo, Adempiere and Compiere (the other contenders) are a bloody mess still relying heavily on PL/SQL code - something simple as adding a new field makes you want to cry for your mom!

[buckmin.erdem.agaoglu.gmail.com]

have a UI that is self generated.

I dont think so. This reminded me of the debate about 'enterprise applications should or can't be sexy' in late 2007. It was simply about the users of ERP systems being frustrated of unusable interfaces and the expectations of the first class ERP customers (CIO's). You can google it for the whole story. I'm not experienced enough to say anything in this kind of discussion but i'm on the 'should be' side. And self-generated UI's are totally in the way of usability.

Correct me if im wrong, self-generated UI's mean exposing your business objects to the users with the toolset available. IMHO there are differences between user profiles/contexts in which the same component in the toolset should be expressed in such different ways that autonomous generators cannot cover by definition. There should be human beings named usability engineers and/or designers.

My point is if you are to design every bits and pieces of UI you need some framework that supports you. No matter how much i like JSF as a technology and no matter how long it lives, i'm not willing to tell the lifecycle, or why they should use POST, or differences between component/tag handlers to my UI engineers. If any of you had success in isolating your UI people in such a level that they get results of their interaction designs while knowing nothing about what is going on behind, please share. I just couldnt, so i had to pick more designer-friendly looking wicket. I hope i didnt make a huge mistake.

[arshadm]

>My point is if you are to design every bits and pieces of UI you need some
>framework that supports you. No matter how much i like JSF as a technology and
>no matter how long it lives, i'm not willing to tell the lifecycle, or why
>they should use POST, or differences between component/tag handlers to my UI
>engineers. If any of you had success in isolating your UI people in such a
>level that they get results of their interaction designs while knowing nothing
>about what is going on behind, please share. I just couldnt, so i had to pick
>more designer-friendly looking wicket. I hope i didnt make a huge mistake.

1. Even though wicket is designer friendly because the front end page is XHTML, doesn't mean that it is in real life. OK, you've just decided to add some extra fields to the database. These fields need to maintained at the UI level, with validation and conversion. Is your designer going to edit the form backing code for you. Or is there still a need for a proper Java developer to change the Java code and compile and deploy for him.

In a Seam/JSF environment the change is much simpler. You simply add the new fields to the appropriate beans, reference them on the page via EL and seam does all the work of ensuring that your model is appropriately validated/updated. If no logic changes are required then no extra code even needs to be touched.

2. As for tag/component handlers confusion. It affects what I would call power users, those doing clever things with Javascript or creating highly configurable pages. The vast majority of use cases are not like that.

3. If you really believe that the UI guys should be completely separated from the Java developers, then that is a huge impedence mismatch in the case of Wicket. At least for JSF, the XHTML file is the definitive source. Now you have two things that need to be kept in sync, nobody in software engineering ever thought that was a clever idea before.

4. I think we should allow the developers to code the web pages and then let desgners use CSS for visual presentation.

Regards.

[buckmin.erdem.agaoglu.gmail.com]

1. Even though wicket is designer friendly because the front end page is XHTML, doesn't mean that it is in real life. OK, you've just decided to add some extra fields to the database. These fields need to maintained at the UI level, with validation and conversion. Is your designer going to edit the form backing code for you. Or is there still a need for a proper Java developer to change the Java code and compile and deploy for him.

My designers or UI related members (as i carefully refer) have PHP and Python/Django background. They will write backing codes both at the first place and whenever a change is required. And IMO they should be. To me an extra database field is never just an extra database field. It should carry some functionality with it both in business layer and user interface beyond just validation/conversion. If it does not, i think i have a problem with my data model at the first place.

In a Seam/JSF environment the change is much simpler. You simply add the new fields to the appropriate beans, reference them on the page via EL and seam does all the work of ensuring that your model is appropriately validated/updated. If no logic changes are required then no extra code even needs to be touched.

This (basic) validation/conversion magic is purely seam. And if wicket is (or going to be) a first class citizen as a view tech, it should be working for it as well. For the second part, i just mentioned maybe its just us but, when we change a bean property we almost always need extra logic. And that extra logic forour UI people working in JSF is plain overkill. I should add that im not implying that wicket is the solution for all this. Im just hopeful.

2. As for tag/component handlers confusion. It affects what I would call power users, those doing clever things with Javascript or creating highly configurable pages. The vast majority of use cases are not like that.

It is subjective, but we need every object of the UI to be usable and pleasing. So we (or our UI people again) always had to do 'clever things with JS'(i'll take that as a compliment). If vast majority of use cases dont need that kind of detail of course they should not be spending time thinking about it. But since the subject is ERP I think they will need 'highly configurable pages'.

3. If you really believe that the UI guys should be completely separated from the Java developers, then that is a huge impedence mismatch in the case of Wicket. At least for JSF, the XHTML file is the definitive source. Now you have two things that need to be kept in sync, nobody in software engineering ever thought that was a clever idea before.

Thanks for lovely compliments but unfortunately i dont believe UI guys should be that seperated. Maybe i should be more specific on UI people def. I'm not talking about artists who do conceptual work on wacom boards. I'm talking about the people to get this concept into a working set of webpages. I believe they should write whatever code is necessary for their cool stuff on pages. If it's a calendar component they should write javascript/css. If it's an ajax call they should write Java/Python/Ruby/PHP for the request endpoint. But they should not care about viewstates, component trees or lifecycles. This brings three options, 1) They dont know all this stuff and eventually cannot do anything cool, 2) They know this stuff and keep swearing on the things they should keep in mind even when doing the simplest job, 3) Throw JSF out of the window.

4. I think we should allow the developers to code the web pages and then let desgners use CSS for visual presentation.

We tried that also, not long ago. Result is flexible structure (add-database-field-and-forget-the-rest like), highly maintainable code, but crappy interface. At the end users didnt even understand what that page is for. It was probably our problem BTW. If your developers can get usable/understandable interfaces just by themselves why should you care.

[mail.micke]

This (basic) validation/conversion magic is purely seam. And if wicket is (or going to be) a first class citizen as a view tech, it should be working for it as well. For the second part, i just mentioned maybe its just us but, when we change a bean property we almost always need extra logic. And that extra logic forour UI people working in JSF is plain overkill. I should add that im not implying that wicket is the solution for all this. Im just hopeful.

No. That is all JSF.

Seam adds some validation helpers, like its tags and the integration with hibernate annotations but that is it.

[buckmin.erdem.agaoglu.gmail.com]

You are correct. I misunderstood the

new fields to the appropriate beans

part only as Hibernate validator annotations. Sorry.

[agresso]

I think it is not yet ready for the large enterprise applications.
You should wait for JSF 2.0

Disadvantages of Jboss seam