You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by Gonzalo Aguilar Delgado <ga...@aguilardelgado.com> on 2013/02/15 14:48:19 UTC

About web technology

Hello, 

I'm still in the process of landing to the project. I find it very
useful and a great place to start with such new technologies. But since
I already said in the users list I want to rise my hand on the web
technologies already used in the project. 

As I said I'm still landing, but looking at the code something is not
clear to me.

Please correct me if wrong.

It seems that there is a rave-web project that contains all the services
needed in the application logic. This project contains a
package ...web.model that has the needed logic to the web page
navigation. 

It has also the tag classes used by jsp and tiles, right?

Ok well, the jsp resources are in rave-portal-* (and some other things).
There is a script that mixes a matches everything. 

Let me propose two things:

-=[First]=-

Forget that old pesky jsp files. While they were good some time ago it
mixes code and design. 

This takes you in the need of getting designers that understand jsp +
tiles. So no much designers are ready for this. 
You will find trouble to get good designs, and visual appearance is what
sells best. After that, the architecture of the project. ;-)

I want to propose use wicket. An apache project with the base of HTML5 +
ajax, that does a great work separating HTML from the code. This will
provide good and clean interfaces that can be tested before merging it
into/with the code.

And more important it relates every html file to one piece of code. With
jsp is difficult to achieve that. Also, you don't have to define any tag
library. It's already done!

[UPDATE (after writing this email, upps)]
I've read the comments of Ate (sorry I missed your answers in my users
list e-mail, until just now ;-) ). 

Yessss!! I agree about a server-side rest and a light-weight javascript
client. But again you will need talented javascript developers. And you
will lose the plain html fallback that you have with wicket. Some uses
links2 here? ;-)
And what happens if the frontend has to do some SOAP to connect any
other service. Have you ever do javascript SOAP? It's a pain. But easy
with server-side technologies. SOAP is just an example but there are
lots of things that are very difficult to do with javascript.

Everyone want javascript (gnome does and it's a desktop application) but
I want to have a backup just in case it makes unpractical. 
Well, you can always do a REST service that makes a SOAP call...  :-P

With the clean separation of the second point we will be able to build
different frontends if we want. 

FYI:
https://github.com/decebals/wicket-dashboard
Seems to fit well in the frontend, for example.


-=[Second]=-

Let me do another proposal. While the rave-web seems to be more or less
clear to me. I find it really to be the core of the backend rest system.
It does nothing about rendering webs. This would be put in an osgi
container in the future like cellar and will work without much
modifications. Let's make clear simpler. 

        1.- Let's call it rave-web-backend (or similar). Remove the web
stuff from it, separate backend and frontend. 
        2.- Let's put web part into the rave-portal -> but rename it to
rave-web-frontend. Join all rave-portal* in this project with the right
maven web structure. So mvn deploy will create a war without the need of
any plugins. 

This will match everything together. 

We can put wicket stuff in rave-web-frontend so it will render the
portal and can be easily replaced with other frontend if you want in the
future, but the services will be set.

Put everything of the frontend there. Resources, html, dependencies,
etc. So one project fits all. If the frontend api grows you can separate
it again and do a rave-web-jar project with the code and leave the rest
in the frontend. That's nice. 

But having 4 projects to build a frontend is a little overbloated. And
more:

*It will not deploy under IDEs*. This means that someone new to this
project will not be able to get hands dirty. Standard maven project
structure will work everywhere. I'm not talking about maintaining
specific IDE configs. Just stick to standard, minimal. Every IDE will
catch it.

In my team nobody takes more than 1h to setup everything and deploy the
projects locally. *Nobody*, this means that there are people that takes
only 10m. 


Thank you a lot for your patience.