UI Components

[rdanner]

This question has been posted before but that was a while ago (maybe lightyears in internet time ;p)

Are we going to pull the alfresco UI components out as a library of its own?
Why not? / When might that occur?

Cheers
-R

[gavinc]

Yes, this has always been our intention, hence the org.alfresco.web.ui.common/org.alfresco.web.ui.repo packages, which represent common JSF components and repository specific components, respectively.

However, it is a lower priority item on the list so it'll probably be later this year.

[rdanner]

Yes, this has always been our intention, hence the org.alfresco.web.ui.common/org.alfresco.web.ui.repo packages, which represent common JSF components and repository specific components, respectively.

However, it is a lower priority item on the list so it'll probably be later this year.

It seems to me that it might be a good approach to donate the non repository UI components to some other opensource project with the condition that alfresco becomes a committer.  It is a good way to lower your engineering risk, responsibility, gives alfresco wider exposure, and ensures that the generic stuff stays decoupled.  It would be a good community gesture.

The repository specific stuff is an interesting thig.  I have been thinking a lot about the web client these days. 

It might be good to put as much of the web client on top of the JCR as possible and then donate that to some JCR community.  Alfresco would then maintain the parts that need to sit on alfresco api for whatever reason.

I see the repository itself as the piece of the pie where alfresco has the power to be the best. The background you have in DM puts you in a unique position for that.

The UI is outstanding (although some think it is too clicky).  Alfresco UI guys are doing a great job. But i would focus most of that work out in to the OSS community.  You get what you give.  It is likely that if the UI is built to be modular and JCR or even Repo agnostic with a plugins for JCR then you will see people start to build models for you with your UI designers as spirit guides.

[rdanner]

Yes, this has always been our intention, hence the org.alfresco.web.ui.common/org.alfresco.web.ui.repo packages, which represent common JSF components and repository specific components, respectively.

However, it is a lower priority item on the list so it'll probably be later this year.

Andy, Gavin.

I spent tonight pulling the Alfresco common UI components out of alfresco.  I have to say I think it is hurting you not having these in their own library right from the beginning.  The common components still have a lot of cohesion to other Alfresco constrcuts. Having these classes compile seperate makes these very obvious. If you want this library to stand alone you are going to have to work hard to decouple them.

There is cohesion with:
Afresco - Looks like some simple refactoring or interfaces can solve most of the issues.
 
Spring - eek
Log4J - should this be common.logging?
MyFaces - Are you tie'n yourself to myfaces? is it worth it?

Also there are import statements that are creating dependencies that dont need to be there.  I have found that eclipse is amazing for this.  If you make it a warning to import unused classes it will indicate where they are for you and you can remove them.  This helps when you refactor.

There are a lot of warnings in these classes but I have not gone back to dig in to that yet.


Anyway there is a ton of awsome work here.

[gavinc]

Yes, you're right, we're aware there are some "unwanted" dependencies that have crept in

As you say the sooner the better before it gets worse, unfortunately, as always, other things get higher priority!

As for Log4J dependencies, yes, they should be commons.logging. We started out using Log4J but some of the client files have managed to avoid re-factoring ops:

Finally, as for tying ourselves to MyFaces, unfortunately where we have done it, it has been necessary. For example, we extend the myfaces portlet bridge to provide file uploading and authentication.

[rdanner]

Yes, you're right, we're aware there are some "unwanted" dependencies that have crept in

As you say the sooner the better before it gets worse, unfortunately, as always, other things get higher priority!

As for Log4J dependencies, yes, they should be commons.logging. We started out using Log4J but some of the client files have managed to avoid re-factoring ops:

Finally, as for tying ourselves to MyFaces, unfortunately where we have done it, it has been necessary. For example, we extend the myfaces portlet bridge to provide file uploading and authentication.

How much is this code evolving?  Maybe we can work together on it.

[paulhh]

Russ

Definitely getting help on this would be great - we always wanted to get as many of the JSF components separated out as possible.  As the guys have mentioned, we've been a bit on a sprint to get a core product out - and after 1.2 there's a couple of immediate missing bits, but then we're going to spend some time opening things up (repo bundle, JSF components, extension hooks, skinning).

Cheers
Paul.

[rdanner]

Russ

Definitely getting help on this would be great - we always wanted to get as many of the JSF components separated out as possible.  As the guys have mentioned, we've been a bit on a sprint to get a core product out - and after 1.2 there's a couple of immediate missing bits, but then we're going to spend some time opening things up (repo bundle, JSF components, extension hooks, skinning).

Cheers
Paul.

Paul,

I have pulled out a bunch of components and separeated thier link with alfresco.  Ofcourse we would probably be looking for a pattern to hook the alfresco stuff back in to the components at run time.  Anyway I am a little swamped at the moment on some ugilier stuff.  I am trying to make several instances of the same portlet (JSF Bridged portlets) work properly together and on top of that publish and subscribe messages from eachother.

The road is full of pot holes.