After having previously read a number of forum posts requesting for an ajax client for ADempiere, I finally decided to go for it.
During my feasibility study on the topic, I came across several posts on the matter whereby most of the people forecast such implementation, should be made on technologies like GWT and echo2. Though both of them are state-of-the art frameworks for web applications, I did not opt for any of them because for me the "open source" nature of the technology was vital.
Being a sourceforge member, I have always been interested in knowing latest trends in OSS development and that's how I came to know about ZK (http://sourceforge.net/projects/zk1). For me it was obvious that ZK was the ideal candidate framework for building a web ui for ADempiere. The reasons are as follows:
1. Being a supporter of ADempiere since its creation, I always like to see its activity ranking in sourceforge and to what I remember ZK has always been in the top most active projects in the past months and sometimes even having a higher ranking than ADempiere (like some hours back).
2. ZK has a lively community and releases are often.
3. ZK has a very good road map and kind-like to be integrated with other technologies and frameworks (Hibernate, Groovy, jRuby, googlemaps, ...).
4. After looking at the codes of ZK and the goals that it aims, I immediately realised the flexibility that could be obtained by using ZK as framework by using pure java coding of web forms and/or the scripting features that it supports natively.
I have already implemented a POC for the web ui and can be downloaded from the following link:
No Conceptual Prototype!!!. All the forms that you have seen are being dynamically generated.
Credits also goes to you and especially to JH, with all the changes in UI implementation he has been requiring for, I hence got a better understanding of the whole concept of Compiere/ADempiere UI and the good job done by JJ.
Kind Regards,
Ashley G Ramdass
posterita
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not that difficult to implement the UI functionality completely with ZK. In fact ZK is quite easy for people knowing Swing and HTML for the scripting. Have done some of the major core codes to enable ADempiere UI functionalities to be able to inter-operate with ZK framework, thus requiring very much less codes. All the core logic for UI retrieval from AD is being untouched.
Above all, the ZK scripting functionality may also be very useful especially for designing custom forms.
Kind Regard,
Ashley G Ramdass
posterita
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> How much effort you have invested upto now? (Ramiro)
Well most of my efforts have gone to get the concept right and not getting the UI right. Commnents on screen layout will be most welcomed.
My major targets have always been code re-use and not touching ADempiere core at all. For the moment I think I have got that right, only the Env class is overloaded and re-written some of the A and V prefix classes.
> how much would it be required in order to have an alpha version for initial testing? (Ramiro)
Well I can't give you any estimation when an Alpha version will be ready, but I will try my best to get an online demo for next week.
> Everybody is so existed and I don't have a windows machine right here now :( Bummer! (Johannes)
No worries. Next demo will be available online. :)
Kind Regards,
Ashley
posterita
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually I was trying to have an idea of how many hours you had spent developing the POC and how many more manhours you foresee were needed to complete an alpha version in order to understand how productive working with ZK was. I was not actually asking for a date on when the alpha would be ready.
Thanks anyway.
Ramiro
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Basically I estimate the number of hours that I spent in developing the POC as 40 Hours, all of these have been during week ends. In fact I really got it working only on Monday, 12th March as I got a longer week end (Monday was public holiday - Independence, Republic day in Mauritius). I currently foresee about 100 man hours be able to get to an alpha version (Have to refactor some codes as I really wanted to get that working).
I think it is also worth mentioning that there has been lot of research work before actually doing the coding and also the understanding of Compiere/ADempiere core & UI logic I have got as a developer for posterita.
All further questions and comments on your side are the most welcomed.
Kind Regards,
Ashley
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Could be a topic at the CC meeting? If they haven't already, maybe it would be good for Ashley, hengsin, and kontro to get together and synchronize approaches. Maybe someone could do a write-up for dummies on the relationship between ZK, TANG, and AJAX?
Very excited about all this,
Joel Stangeland
www.idalica.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks to Ashley and Posterita for being proactive on a web UI. This is just what we need to get things atarted.
I would like to see some structure around this development effort, much like the roadmaps for new versions, next generation (Tang), etc. Below are my thoughts. But first I want to give a little background about myself so you know where I'm coming from.
I've been doing ERP, mostly as a technical consultant, for over eight years. Half that time was with Oracle. My primary function there was to write web interfaces to various modules of Oracle Apps. This included HR/Payroll, Project Accounting (for time and expense entry), and CRM/SFA.
As far as Compiere and Adempiere are concerned I am very familiar with Jorg's original approach using the servlets that can be found in org.compiere.www. We have done several custom web interfaces that re-used these servlets. We modified them to not generate the final HTML, and instead opted for Struts and JSP's. This is a pretty typical approach.
I am also very knowledgeable of the AD so I am aware of all the integration points necessary for a fully dynamic web UI. I am also aware of unfortunate limitations like dependencies on Table and Column that control field rendering on windows.
Philosophically my opinion on web UI's in enterprise applications is that they should be as light weight as possible. The application should do all the heavy lifting, and configuration changes in the core app should always propogate to the web app without having to change code or redeploy.
Now that you know some background about me, here are my thoughts on the roadmap for a web UI in Adempiere:
1) Choose a MVC framework. I have been playing around with JSF and so far am pretty impressed. We will be using this going forward instead of Struts.
2) Must be AD driven. I doubt any will disagree on this point.
3) Do not reuse any of the existing code from Compiere such as that found in org.compiere.www, the WebEnv or WebSessionContext classes (this is a reversal of my previous position some months ago). While my motives here are technical, I believe it offers the added benefit of the web UI being truly independent of Compiere copyright.
4) DO NOT use the single window, mulitple frame structure that Jorg created. The web UI should allow for multiple windows to be open at once, just like the thick client. And in my opinion the menu window should also be it's own floating window (again, just like thick client.)
5) Don't go overboard on UI design. We just need to get something out that works well. There is nothing wrong with having a first generation web UI that looks just like the thick client. It would be familiar to users. This is an important point. I experienced fearful users when we switched from Compiere to Adempiere simply because the icons were different!
There could be a refactoring of the web UI once Tang is done. For example, deploy to web app servers without having to distribute the entire code base.
General comments on design:
* Continue with the concept of a "context" as is done in the old web UI as well as thick client. However, minimize information stored in session. Page context will be part of request object and with a framework like JSF will automatically handle population of form beans, backing beans, etc.
* Ajax is great but I don't see it as critical to the foundation. Most pages don't have that much data, and round trips to the server are pretty inexpensive for most screens. I would envision Ajax components evolving on top of a solid MVC foundation that is fully functional in its own right.
* Minimal JavaScript, only for triggering events. This preserves things like callouts consistently working between web UI and thick cleint. Also helps with browser independence.
* Other comments to follow as others post....
I have a working login based on JSF that I would be willing to contribute. I haven't gotten very far and could use some help. It is structured as a web project in Eclipse using WTP. I would commit it in that structure. Others can do as they wish.
If someone will advise me on how to best contribute this code I will do so. Can I just create a folder under contributions?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i would like to thank you for commiting JSF prototype.
Regarding WEB UI of Adempiere i would like to ask one question and to express my concerns.
At the moment in SVN repositiry i see three places where Adempiere model classes can be found:
1) trunk/dbPort/src...
2) /contributions/posterita/WEB-INF/src/org/posterita/beans
Here i see beans which do not extend X_ classes but have the same methods (get and set).
3) /contributions/GlobalEra/ui/src/org/compiere/model
Here i see Model classes from Adempiere.
My question is how WEB UI developers see future integration of WEB UI with main Adempiere core.
1.1) When someone change model class in dbPort whould he need to change it into all other places?
For posterita i see that it is not necessary. But i would like to have developers opinion too.
1.2) Does WEB UI reuse business logic from Adempiere callouts and logic from AD_Column and AD_Field (read only Logic; Default Value; Dynamic Validation; ...)
1.3) Isn't it WEB UI too slow and hard/expensive to maintain witout 3 tier model?
Kind regards,
Trifon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Vince, yes u can open up a folder under contributions. I will check that u are in our developer's list with write access. U can name the sub folder Global Era for easy ID sake as well as branding.
Like i said elsewhere u can even submit File Release as a binary zipped compiled running version of what u done without releasing the source yet. This is for convenience and iterative progression as we are overwhelmed with too much projects to look at. The steps i proposing to all is
1) Give your demo movies so that ppl can quickly know what u re doing
2) Submit a comppiled version or online demo so that ppl can test it out for themselves.
3) When encouraged, u can then submit sources for ppl to study deeper
4) When it matures, a 2pack or ADCK module is worked out and posted
When posting files to SVN, u can always have it under your own namesake folder/package. I have just created one for Posterita and committed their movies there. Next we will ask them to commit their compiled binaries. They have already done their contribution/posterita since day 1 so that is covered.
Btw Vince, it be now recommended that you also appear in Berlin this May end. U can showcase your system to us as well as brainstorm closely with the core team that shall be there about the Web UI. Then when we return with the right picture it saves us all round and in the long term alot of rewards.
red1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We are working on that too Vince! (malaysian trip). And whatever u put out about your vertical greatly helps. I like to see some screenshots at least, and a working binary (DB Dump & app if any) uploaded to our File Releases ( if u do not know how u can pass me a link to your FTP and i upload it for u). This binary u can strip off all sensitive data and just leave the working configs for ppl to examine. Like i said in your case source doesnt matter. It is subject matter.
red1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi ADemperians,
After having previously read a number of forum posts requesting for an ajax client for ADempiere, I finally decided to go for it.
During my feasibility study on the topic, I came across several posts on the matter whereby most of the people forecast such implementation, should be made on technologies like GWT and echo2. Though both of them are state-of-the art frameworks for web applications, I did not opt for any of them because for me the "open source" nature of the technology was vital.
Being a sourceforge member, I have always been interested in knowing latest trends in OSS development and that's how I came to know about ZK (http://sourceforge.net/projects/zk1). For me it was obvious that ZK was the ideal candidate framework for building a web ui for ADempiere. The reasons are as follows:
1. Being a supporter of ADempiere since its creation, I always like to see its activity ranking in sourceforge and to what I remember ZK has always been in the top most active projects in the past months and sometimes even having a higher ranking than ADempiere (like some hours back).
2. ZK has a lively community and releases are often.
3. ZK has a very good road map and kind-like to be integrated with other technologies and frameworks (Hibernate, Groovy, jRuby, googlemaps, ...).
4. After looking at the codes of ZK and the goals that it aims, I immediately realised the flexibility that could be obtained by using ZK as framework by using pure java coding of web forms and/or the scripting features that it supports natively.
I have already implemented a POC for the web ui and can be downloaded from the following link:
http://www.posterita.org/share/WebUIAdempierePosterita.EXE
All your comments and help will be the most welcomed.
Kind Regards,
Ashley G Ramdass
posterita
Ashley,
Awesome demo! Are those screens painting dynamically from the ADempiere AD? Or is it a conceptual prototype?
Thanks, JS
Joel Stangeland
www.idalica.com
Looks excellent!
This is actually how it is working? Amazing!, How difficult is to develop with this framework?
Best Regards!
Hi Ashley,
it looks very good.
Kind regards,
Trifon
Thanks JS.
No Conceptual Prototype!!!. All the forms that you have seen are being dynamically generated.
Credits also goes to you and especially to JH, with all the changes in UI implementation he has been requiring for, I hence got a better understanding of the whole concept of Compiere/ADempiere UI and the good job done by JJ.
Kind Regards,
Ashley G Ramdass
posterita
Thanks Moyses.
Not that difficult to implement the UI functionality completely with ZK. In fact ZK is quite easy for people knowing Swing and HTML for the scripting. Have done some of the major core codes to enable ADempiere UI functionalities to be able to inter-operate with ZK framework, thus requiring very much less codes. All the core logic for UI retrieval from AD is being untouched.
Above all, the ZK scripting functionality may also be very useful especially for designing custom forms.
Kind Regard,
Ashley G Ramdass
posterita
Thanks Trifon.
Still some more work needed to get that up and running perfectly.
Kind Regards,
Ashley G Ramdass
posterita
COOL.
Great job.
Ashley,
This is just outstanding!
How much effort you have invested upto now?, how much would it be required in order to have an alpha version for initial testing?
Thanks for your work!
Ramiro
Hi,
the demo is really stunning.
A compliment to the Posterita guys.
Mario Calderon
Hi Ashley
It's really dazzling! I'm totally impressed! Thank you!
Warm regards,
Bahman
Everybody is so existed and I don't have a windows machine right here now :(
Bummer!
Best regards Johannes
Thank you to all of you for your support.
For the questions and comments:
> How much effort you have invested upto now? (Ramiro)
Well most of my efforts have gone to get the concept right and not getting the UI right. Commnents on screen layout will be most welcomed.
My major targets have always been code re-use and not touching ADempiere core at all. For the moment I think I have got that right, only the Env class is overloaded and re-written some of the A and V prefix classes.
> how much would it be required in order to have an alpha version for initial testing? (Ramiro)
Well I can't give you any estimation when an Alpha version will be ready, but I will try my best to get an online demo for next week.
> Everybody is so existed and I don't have a windows machine right here now :( Bummer! (Johannes)
No worries. Next demo will be available online. :)
Kind Regards,
Ashley
posterita
Ashlet,
Actually I was trying to have an idea of how many hours you had spent developing the POC and how many more manhours you foresee were needed to complete an alpha version in order to understand how productive working with ZK was. I was not actually asking for a date on when the alpha would be ready.
Thanks anyway.
Ramiro
Ashle,
Just have to congratulate u there and here! Here is to more surprises.
red1
Hi Ramiro,
Sorry that I misunderstood your question.
Basically I estimate the number of hours that I spent in developing the POC as 40 Hours, all of these have been during week ends. In fact I really got it working only on Monday, 12th March as I got a longer week end (Monday was public holiday - Independence, Republic day in Mauritius). I currently foresee about 100 man hours be able to get to an alpha version (Have to refactor some codes as I really wanted to get that working).
I think it is also worth mentioning that there has been lot of research work before actually doing the coding and also the understanding of Compiere/ADempiere core & UI logic I have got as a developer for posterita.
All further questions and comments on your side are the most welcomed.
Kind Regards,
Ashley
Thank you very much red1.
Kind Regards,
Ashley
posterita
Hello Geniuses,
Could be a topic at the CC meeting? If they haven't already, maybe it would be good for Ashley, hengsin, and kontro to get together and synchronize approaches. Maybe someone could do a write-up for dummies on the relationship between ZK, TANG, and AJAX?
Very excited about all this,
Joel Stangeland
www.idalica.com
Thanks JS.
It will be an honour for me to work with Hengsin and Kontro.
I am also very excited about how the things have been going recently.
I will do my best to help ADempiere get to its Next Generation.
Kind Regards,
Ashley
posterita
Thanks to Ashley and Posterita for being proactive on a web UI. This is just what we need to get things atarted.
I would like to see some structure around this development effort, much like the roadmaps for new versions, next generation (Tang), etc. Below are my thoughts. But first I want to give a little background about myself so you know where I'm coming from.
I've been doing ERP, mostly as a technical consultant, for over eight years. Half that time was with Oracle. My primary function there was to write web interfaces to various modules of Oracle Apps. This included HR/Payroll, Project Accounting (for time and expense entry), and CRM/SFA.
As far as Compiere and Adempiere are concerned I am very familiar with Jorg's original approach using the servlets that can be found in org.compiere.www. We have done several custom web interfaces that re-used these servlets. We modified them to not generate the final HTML, and instead opted for Struts and JSP's. This is a pretty typical approach.
I am also very knowledgeable of the AD so I am aware of all the integration points necessary for a fully dynamic web UI. I am also aware of unfortunate limitations like dependencies on Table and Column that control field rendering on windows.
Philosophically my opinion on web UI's in enterprise applications is that they should be as light weight as possible. The application should do all the heavy lifting, and configuration changes in the core app should always propogate to the web app without having to change code or redeploy.
Now that you know some background about me, here are my thoughts on the roadmap for a web UI in Adempiere:
1) Choose a MVC framework. I have been playing around with JSF and so far am pretty impressed. We will be using this going forward instead of Struts.
2) Must be AD driven. I doubt any will disagree on this point.
3) Do not reuse any of the existing code from Compiere such as that found in org.compiere.www, the WebEnv or WebSessionContext classes (this is a reversal of my previous position some months ago). While my motives here are technical, I believe it offers the added benefit of the web UI being truly independent of Compiere copyright.
4) DO NOT use the single window, mulitple frame structure that Jorg created. The web UI should allow for multiple windows to be open at once, just like the thick client. And in my opinion the menu window should also be it's own floating window (again, just like thick client.)
5) Don't go overboard on UI design. We just need to get something out that works well. There is nothing wrong with having a first generation web UI that looks just like the thick client. It would be familiar to users. This is an important point. I experienced fearful users when we switched from Compiere to Adempiere simply because the icons were different!
There could be a refactoring of the web UI once Tang is done. For example, deploy to web app servers without having to distribute the entire code base.
General comments on design:
* Continue with the concept of a "context" as is done in the old web UI as well as thick client. However, minimize information stored in session. Page context will be part of request object and with a framework like JSF will automatically handle population of form beans, backing beans, etc.
* Ajax is great but I don't see it as critical to the foundation. Most pages don't have that much data, and round trips to the server are pretty inexpensive for most screens. I would envision Ajax components evolving on top of a solid MVC foundation that is fully functional in its own right.
* Minimal JavaScript, only for triggering events. This preserves things like callouts consistently working between web UI and thick cleint. Also helps with browser independence.
* Other comments to follow as others post....
I have a working login based on JSF that I would be willing to contribute. I haven't gotten very far and could use some help. It is structured as a web project in Eclipse using WTP. I would commit it in that structure. Others can do as they wish.
If someone will advise me on how to best contribute this code I will do so. Can I just create a folder under contributions?
Hi Vince Clark,
i would like to thank you for commiting JSF prototype.
Regarding WEB UI of Adempiere i would like to ask one question and to express my concerns.
At the moment in SVN repositiry i see three places where Adempiere model classes can be found:
1) trunk/dbPort/src...
2) /contributions/posterita/WEB-INF/src/org/posterita/beans
Here i see beans which do not extend X_ classes but have the same methods (get and set).
and here:
/contributions/posterita/WEB-INF/src/org/posterita/model
3) /contributions/GlobalEra/ui/src/org/compiere/model
Here i see Model classes from Adempiere.
My question is how WEB UI developers see future integration of WEB UI with main Adempiere core.
1.1) When someone change model class in dbPort whould he need to change it into all other places?
For posterita i see that it is not necessary. But i would like to have developers opinion too.
1.2) Does WEB UI reuse business logic from Adempiere callouts and logic from AD_Column and AD_Field (read only Logic; Default Value; Dynamic Validation; ...)
1.3) Isn't it WEB UI too slow and hard/expensive to maintain witout 3 tier model?
Kind regards,
Trifon
Vince, yes u can open up a folder under contributions. I will check that u are in our developer's list with write access. U can name the sub folder Global Era for easy ID sake as well as branding.
Like i said elsewhere u can even submit File Release as a binary zipped compiled running version of what u done without releasing the source yet. This is for convenience and iterative progression as we are overwhelmed with too much projects to look at. The steps i proposing to all is
1) Give your demo movies so that ppl can quickly know what u re doing
2) Submit a comppiled version or online demo so that ppl can test it out for themselves.
3) When encouraged, u can then submit sources for ppl to study deeper
4) When it matures, a 2pack or ADCK module is worked out and posted
When posting files to SVN, u can always have it under your own namesake folder/package. I have just created one for Posterita and committed their movies there. Next we will ask them to commit their compiled binaries. They have already done their contribution/posterita since day 1 so that is covered.
Btw Vince, it be now recommended that you also appear in Berlin this May end. U can showcase your system to us as well as brainstorm closely with the core team that shall be there about the Web UI. Then when we return with the right picture it saves us all round and in the long term alot of rewards.
red1
Thanks red1. I was hoping for an all expenses paid trip to Malaysia. But I would love to be in Berlin. I'll see what I can do.
Initial contribution for JSF based web ui is now in contributions under GlobalEra/ui
We are working on that too Vince! (malaysian trip). And whatever u put out about your vertical greatly helps. I like to see some screenshots at least, and a working binary (DB Dump & app if any) uploaded to our File Releases ( if u do not know how u can pass me a link to your FTP and i upload it for u). This binary u can strip off all sensitive data and just leave the working configs for ppl to examine. Like i said in your case source doesnt matter. It is subject matter.
red1