JBossDeveloper

I agree with Thomas. The Admin UI is a separated thing. For the designer / prototyping role we have the Site Publisher. 

By talking to some consultants / users, they declarated that they use the UI for the admin role. So it's exactly what we're trying to do, talking to people to find out what they use the most.

Thanks for your feedback. The idea is to refine this prototype and to foster discussion.

GateIn Portal can be the base of a product ....

Yes... and I believe that several variant product can be built out of this base.

For a proper answer to a so wide spectrum, I believe that it would become a burden (or "une usine à gaz") to try to do it with only one product.

On a marketing point of view, it is also very very difficult to have only one product to address so wide a spectrum of needs.

I agree with what you say... and wish that a move a bit more further is dared : several product, to "talk" to 2 or 3 market segments.

**************

How do you see "designer and prototype building role" affecting the admin UI ?

Globally, for the time being, the UI as it is is quite ok.

To refine it a bit :

- All that is "Admin for prod admin", is then not necessary.

- Keep the nice feature dedicated to building new pages, modifying them etc....

A) All that is "Admin for prod admin", is then not necessary.

as an example, the setting of the property for "Keep Session Alive" is not really needed for prototyping.

It could be put is a module for : building the portals bases... with all the settings, including the very technical and prod administration ones.

B) Keep the nice feature dedicated to building new pages, modifying them etc....

The "view as it is", when building a page content, is very nice.

The button for switching from one view, to another (with "content blind frames"), can be enhanced.

Also, opening the page modification directly when being in the page, is nice.

(like the document modification, in site publisher... for what I recall of this nice feature).

For my use, and way of conselling client teams on how to working with the portal and build their portal, I use the UI as it is for the prototyping.

For this kind of project, this is ok as it is.

The size of the project, and the effort and means involved for building and start the run of the portal is big.

The prototyping, and then writting the xml files corresponding is a small task, compared to the other things.

This UI is not critical.

The customer does not "buy" the EPP product, or the GateIn community product, for the UI.

It is just a convenient tool.

And Eclipse plugin might also be welcome, ... more near of J2EE development environment, than "easy web interface tool for building small web sites".

That the way I see things are going on,... at customers.

Since 2005, I have worked on about 9 projects, in 9 different companies (one in belgium, one in Luxembourg, the others in France).

Antoine

@Gabriel

I have not look that much to Site Publisher.

For me, it is a WCM... not a portal page prototyper.

For what I have seen of this nice product,.... yes, It may do it, for the prototyping role.

So ok for using Site Publisher (or community Exo WCM ?) for the prototyping of a portal.

As I say, the UI is not critical.

**********

I have tried to use the UI for the Admin, but I never could see how to use this tool and way of settling a J2EE portal project with it.

I may have missed something ....

**********

main problem : how to work this way, with several dev teams working with several parts of a portal (for a real J2EE portal project, not a quick web site) ?

how to work this way, for a project that must have Dev-Test-Approval-Prod cycle and servers for each step ?

I have yet posted about all this... may be one or two years ago.

The export-import is now giving a way to work with the Admin UI, with a Dev-Test-Approval-Prod cycle.

But... the tool is specific to GateIn Portal... and prod guys does not like to have this kind of specific tools.

(especially in nice J2EE and JBoss prod... they know and use the standard tools... and do not want "a tool by application").

And ... the export does not export the Gadget Definition, nor the Portlet Def....

So they must be done in some XML file (for transport among the several dev teams, and in the Dev-Test-Approval-Prod cycle).

And the developers must not use the UI to declare them....

etc...

etc...

problems, ... "compliqué", ... "bidouille de scripts d'export et d'import".... "this is ok for the page and nav, but not for gadget def....".

much more easy and reliable to work with XML definition in wars and jars, and use the standard tools : CVS/Subversion, maven, J2EE deployement on JBoss (or Tomcat).

then, the rule is : use the UI for checking sometime something in the config of the portal,... but do not use it in write mode : none of is is kept for the "Dev-Test-Approval-Prod cycle".

**********

Another problem :

with jboss portal, we add the hot deployement of the portal and pages definition.

without the hot deployement, and with gatein, you have to clean the database, for the modification to be taken into account.

(I have seen that there is a new option, in the 3.2 version... have to look at it... it seems we can now "merge" the new XML definition with what is in the database).

when working with several dev teams,... the work on their specific part of the portal.

they have the portal on each developper local machine.

they cannot say to the other of the teams : "hey guys, I stop the server to reload the page definition... stop your work on the server..."

then, with "several portal parts developped on each machine",... how to merge all this work ?

with a database merge ???

with the import merge ??? that is a blind tool, you launch it and hope it merge properly all these page ... with no check that you are not overwriting the work of another dev guys on the same page ???

no way...

CVS or Subversion on xml definition, nicely stored in classical ear, war or jar,... are much more easy.

**********

I hope these scenarios and situations from portal project will help.

Feel free to ask any question about all this.

Antoine