I think this should probably be a standalone plugin for now, we can move it into the core later as it matures!

Go ahead and open a ticket in FORGEPLUGINS if you want one to track this. Hopefully we will have our plugin site up and running soon so you won't need to create JIRAs, you'll just create an account and get writing!

Looking forward to seeing what you come up with!
~Lincoln

On Mon, Apr 2, 2012 at 9:35 AM, Ken Finnigan <ken@kenfinnigan.me> wrote:
Hi Jérémie,

Thanks for putting an initial portal plugin together.  It was something on my list for the months ahead, but you beat me to it! ;-)

I've responded in line to your questions.

Regards
Ken

On Sun, Apr 1, 2012 at 3:00 PM, Jérémie <jer@printstacktrace.org> wrote:
Hi Forge Team!

I would like to create a plugin to manage javaee portlets.
A first commit is available here http://goo.gl/OKgsG . 

Before going further and create a Forge Jira ticket  I would appreciate your opinion.
 - Do you think core/javaee-api and core /javaee-impl  is a right place or I need to create an other project?

I think this is the correct place, though Lincoln would have the final say on that ;-)
 
 - The JBoss Shrinkwrap project doesn't currently include the portlet.xml description. I think it's interesting to do that. (I can create an other Jira ticket)

By all means go ahead and create the jira and do the work.  It would be quite straight forward to complete.  I myself did the JSF ones last week, and was planning on getting to portal descriptors over the coming weeks.  It's just a case of adding the necessary xsd files, making sure the generation process worked, and writing some tests to verify it.  If you have any questions about it drop by #jbosstesting on irc and speak with Andrew (ALR) who leads the project.
 
 - The quickstart option  would be interesting to push the generated code in a GateIn instance (not implemented yet).

You could certainly do a deploy of the portlet to GateIn, or any other portal, but I think it makes sense for that to be a separate concern from creating a portlet and it's descriptors.  That is how a lot of the other plugins work, and also because the deployment would be specific to GateIn, and it would be messy to have a plugin that deals with descriptor generation and deploying to different portal containers.
 
 - Command names and options are correct?
Thanks for your comments.

For now here's what you can do: 
 $ portlet setup
 $ portlet add --named helloportlet --title "My forge portlet" --short-title ForgePortlet --keywords "demo,forge,portlet"

Might make it clearer for command to be called "new-portlet" instead of "add"
 
 $ portlet add-param --portlet helloportlet --name javax.portlet.faces.defaultViewId.view --value "/home.xhtml"
 $ portlet add-param --portlet helloportlet --name javax.portlet.faces.defaultViewId.edit --value "/edit.xhtml"
 $ portlet add-param --portlet helloportlet --name javax.portlet.faces.defaultViewId.help --value "/help.xhtml"

Could be nice to have the "new-portlet" command automatically create these parameters with the default values you specify above, as without them a portlet won't deploy successfully.  Just as you have with the default portlet modes that are defined.
 
It would also be nice to have aliased add-param versions for specifically adding a view, edit and help viewId.  It's pretty onerous to force someone to remember the exact syntax of javax.portlet.faces.defaultViewId.* every time they want to add or modify what viewId each of those portlet modes points at.

So you could have something like:
$ portlet set-view-id --portlet helloportlet --view "/home.html"
$ portlet set-edit-id --portlet helloportlet --view "/edit.html"
$ portlet set-help-id --portlet helloportlet --view "/help.html"

and then internally it actually calls add-param with the addition of the appropriate param name.


And the result is :
src/main/webapp/WEB-INF/portlet.xml
-----------------------------------------------------
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  <portlet>
    <portlet-name>helloportlet</portlet-name>
    <portlet-class>javax.portlet.faces.GenericFacesPortlet</portlet-class>
    <supports>
      <mime-type>text/html</mime-type>
      <portlet-mode>EDIT</portlet-mode>
      <portlet-mode>HELP</portlet-mode>
      <portlet-mode>VIEW</portlet-mode>
    </supports>
    <portlet-info>
      <title>My forge portlet</title>
      <short-title>ForgePortlet</short-title>
      <keywords>demo,forge,portlet</keywords>
    </portlet-info>
    <init-param>
      <name>javax.portlet.faces.defaultViewId.view</name>
      <value>/home.xhtml</value>
    </init-param>
    <init-param>
      <name>javax.portlet.faces.defaultViewId.edit</name>
      <value>/edit.xhtml</value>
    </init-param>
    <init-param>
      <name>javax.portlet.faces.defaultViewId.help</name>
      <value>/help.xhtml</value>
    </init-param>
  </portlet>
</portlet-app>


Regads,
Jérémie.

_______________________________________________
forge-dev mailing list
forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev



_______________________________________________
forge-dev mailing list
forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev




--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."