[aerogear-dev] Aerogear Forge Plugin
Sebastien Blanc
scm.blanc at gmail.com
Fri Mar 1 04:39:49 EST 2013
Hi Richard,
Thanks for the detailed feedback. Your "attribute required" use case is
indeed interesting but I think this could be solved by following a
convention, I'm a big fan of Convention Over Configuration : I prefer
having a convention like "When processing search macro/template/partial
attributes are not required" rather than configure a bundle of XML files
and implement Java classes.
The two approaches are valid and even if we follow the coc way there must
always be a way to override the convention.
Seb
On Thu, Feb 28, 2013 at 1:42 AM, Richard Kennard <
richard at kennardconsulting.com> wrote:
> Seb,
>
> Thanks for putting that together. It appears we agree more than we
> disagree! To recap:
>
> 1. We agree 'inspecting metadata' needs to be orthogonal to 'widget
> building'. You are re-using Metawidget's Inspectors, which is great
> 2. We agree 'widget building' needs to be orthogonal to layout. Not just
> to avoid duplicating code, but also so you can make it pluggable (i.e. your
> 'custom.tpl')
> 3. We agree that layout needs to be orthogonal to the wider page (i.e. we
> do everything inside a 'div' or 'table' - neither of us are trying to render
> everything from the 'html' tag down)
>
> You decided FreeMarker was a good fit for #3, and I agree with you. I've
> implemented a FreemarkerLayout for the next version of Metawidget. I've
> blogged
> about it and put together an example you can download here:
>
> http://blog.kennardconsulting.com/2013/02/metawidget-meets-freemarker.html
>
> So our main area of disagreement remains: is FreeMarker a good fit for #2?
>
> I think not. Not because of FreeMarker's templating language per se, but
> because *FreeMarker returns strings*. This makes it hard to do meaningful
> post-processing on the chosen widget before inserting it into the layout.
> There are many examples of why post-processing is important. Let me give
> you one:
>
> 1. In the existing JSF scaffold, some fields are 'required' (i.e.
> not-null) fields. We add the JSF 'required' attribute to these widgets. You
> do something
> similar in your code:
>
> <#if (property.required!"false") == "true"> required</#if>
>
> However, we do this in a separate RequiredAttributeProcessor - not in the
> WidgetBuilder. The reason is, although we use RequiredAttributeProcessor on
> the
> editing screen, we swap it out for the search screen. The search screen
> still needs to read the same metadata, and generate the same widgets, and
> lay out
> in the same way, as the editing screen. But it does *not* want those
> widgets to be 'required', because search fields are optional.
>
> Search screens are used in a different way to editing screens. So there is
> value in making 'required/not required' orthogonal to 'choice of widget'. We
> don't want to duplicate the whole 'widget choosing' code just so we can
> relax the 'required' attribute.
>
> Regards,
>
> Richard.
>
> On 27/02/2013 10:19 PM, Sebastien Blanc wrote:
> > Richard,
> > You are totally right by saying than maintaining a 500 characters long
> line will be a nightmare and the current implementation was just a first
> try.
> > Vineet as started to factorize the code into macros, you can see it here
> :
> >
> https://github.com/forge/scaffold-html5/blob/master/src/main/resources/scaffold/angularjs/views/includes/basicPropertyDetail.html.ftl
> >
> > But in the same time, we are working on an architecture that will have a
> single/common point of entry for the "widget choosing code" and we can plug
> > whatever widget renderer template into it. To make this easier, I have
> created a simple project ,just for you ;) , to demonstrate the main concept.
> >
> > https://github.com/sebastienblanc/freemarkertests
> >
> > You will see the default renderer (renderer.tpl) and a custom renderer
> (custom.tpl). The testcases will use the same "widget selector" but their
> "own"
> > renderer. A custom widget renderer template can override all the
> widgets or only some of them, it is very flexible.
> >
> > Please feel free to provide any feedback.
> >
> > Best Regards,
> > Seb
> >
> >
> >
> > On Tue, Feb 26, 2013 at 10:49 PM, Richard Kennard <
> richard at kennardconsulting.com <mailto:richard at kennardconsulting.com>>
> wrote:
> >
> > Seb,
> >
> > Thank you for your feedback.
> >
> > I'm afraid we'll need to agree to disagree that Freemarker is a good
> medium for implementing 'widget choosing' code. Your current implementation
> is
> > basically a single line that is 500 characters long. I fear this
> will become a rapidly worsening maintenance problem.
> >
> > However you make a good point about using Freemarker for the layout.
> I will look at implementing a FreemarkerLayout into Metawidget.
> >
> > Regards,
> >
> > Richard.
> >
> > On 26/02/2013 8:48 PM, Sebastien Blanc wrote:
> > >
> > >
> > > On Tue, Feb 26, 2013 at 10:40 AM, Richard Kennard <
> richard at kennardconsulting.com <mailto:richard at kennardconsulting.com>
> > <mailto:richard at kennardconsulting.com <mailto:
> richard at kennardconsulting.com>>> wrote:
> > >
> > > Seb,
> > >
> > > It sounds like there may be some convergence here. Your
> 'macros' library may end up looking very similar to Metawidget's existing
> HTML5
> > > WidgetBuilder. And
> > > your 'composition plugins' may end up similar to Metawidget's
> LayoutDecorators and Layouts.
> > >
> > > I'd like to make sure you're not re-inventing the wheel here?
> Is your main driver that you prefer writing templates in Freemarker to Java
> code?
> > >
> > >
> > > Absolutely :) ! A user should be able to read and understand a
> template / overload them and not forced to write a Java class, a mid-term
> vision is
> > to be
> > > more and more polyglot.
> > > Seb
> > >
> > >
> > > Regards.
> > >
> > > Richard.
> > >
> > > On 26/02/2013 8:31 PM, Sebastien Blanc wrote:
> > > > Hi Richard,
> > > > Thanks for your remarks and questions, see my comments
> inline.
> > > >
> > > > On Tue, Feb 26, 2013 at 10:06 AM, Richard Kennard <
> richard at kennardconsulting.com <mailto:richard at kennardconsulting.com>
> > <mailto:richard at kennardconsulting.com <mailto:
> richard at kennardconsulting.com>>
> > > <mailto:richard at kennardconsulting.com <mailto:
> richard at kennardconsulting.com> <mailto:richard at kennardconsulting.com
> > <mailto:richard at kennardconsulting.com>>>> wrote:
> > > >
> > > > Hi Vineet,
> > > >
> > > > Thanks for your detailed response.
> > > >
> > > > I'm not opposed to the idea of a FreemarkerWidget (or
> VelocityWidget, or StringTemplateWidget). Indeed, the early versions of
> Metawidget
> > looked
> > > much like
> > > > you describe: a separate, pluggable inspection layer,
> then a Metawidget to render it.
> > > >
> > > > However, we subsequently got a lot of feedback and did
> many interviews, adoption studies and case studies. This ultimately led to
> the
> > > architecture of
> > > > pluggable WidgetBuilders, WidgetProcessors and Layouts.
> Let me give you 3 examples of the feedback we got:
> > > >
> > > > 1. Widget choice needs to be orthogonal to layout. If
> you look at your 'master.html.ftl' and 'detail.html.ftl' you have a lot of
> duplicated
> > > code between
> > > > them. Both templates contain <#if... #else to choose
> between a 'select' box and a 'text' box. This code is going to inflate
> rapidly once you
> > > add your
> > > > date
> > > > pickers, telephone numbers, URLs etc. to the mix. Worse,
> such code will need to be duplicated across both templates.
> > > >
> > > >
> > > > Vineet is currently factorizing all the duplicated code
> into Freemarker's Macros, this Macros library will be shared along the
> different
> > plugins.
> > > >
> > > >
> > > > 2. Equally, layout needs to be orthogonal to the wider
> page. Say I decide I want to use tables with rows and columns, instead of a
> div-based
> > > layout.
> > > > Or say
> > > > I want to use different CSS classes to your
> 'control-group' and 'controls'. I will have to do it in both templates. But
> what is *actually*
> > > different
> > > > about
> > > > the templates is the choice of search buttons/results
> versus save/cancel buttons. So the 'middle bit' of each page needs to be
> > orthogonal. This
> > > will get
> > > > worse as you add more templates, such as separate
> 'search', 'view' and 'edit' templates (see the JSF scaffold).
> > > >
> > > > With Forge 2.0 in mind, where Plugins/addons will be able to
> be dependent from each other, inherit from each other, we plan to end up
> with
> > some basic
> > > > plugins which will offer a lot of flexibility to deliver
> "Composition plugins". We are also going to introduce a lot of convention
> over
> > > configuration but
> > > > with keeping in mind that the user can always override the
> conventions.
> > > >
> > > >
> > > > 3. Developers like to use third-party widget libraries,
> and also in-house custom widget libraries. If I want to add RichFaces, or
> > PrimeFaces, or a
> > > > mixture
> > > > of both, I want to be able to do so in a way that is
> orthogonal to all of the above
> > > >
> > > > So my concern would be that a FreemarkerWidget would
> tightly couple widget choice (WidgetBuilders) and layout, and not allow
> widget
> > processing
> > > (which is
> > > > important for other reasons I haven't touched upon).
> Freemarker does, I agree, offer an attractive level of immedicay and
> ease-of-editing
> > > templates.
> > > > But I
> > > > wonder what your thoughts are on how it scales for some
> of the points above?
> > > >
> > > >
> > > > "Scaling" will be partly solved by the new architecture
> explained above. For sure, there will always be situations where the user
> wants to
> > > introduce his
> > > > supra cool custom widget that don't fits without a lot of
> hacking but IMO that's beyond the scope of scaffolding. Scaffolding is just
> to
> > "boost up"
> > > a new
> > > > project, it's a one time action, for sure, we can offer
> entry points for customization but we can't (or don't want to) cover all
> the specific
> > > situations.
> > > >
> > > > Regards,
> > > > Seb
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Richard.
> > > >
> > > > > On 22 February 2013 13:56, Vineet Reynolds Pereira <
> vpereira at redhat.com <mailto:vpereira at redhat.com> <mailto:
> vpereira at redhat.com
> > <mailto:vpereira at redhat.com>> <mailto:vpereira at redhat.com <mailto:
> vpereira at redhat.com>
> > > <mailto:vpereira at redhat.com <mailto:vpereira at redhat.com>>>
> <mailto:vpereira at redhat.com <mailto:vpereira at redhat.com> <mailto:
> vpereira at redhat.com
> > <mailto:vpereira at redhat.com>>
> > > > <mailto:vpereira at redhat.com <mailto:vpereira at redhat.com>
> <mailto:vpereira at redhat.com <mailto:vpereira at redhat.com>>>>> wrote:
> > > > >
> > > > > Hi Richard,
> > > > >
> > > > > I'm glad you brought this up, since we've been
> looking to provide feedback once we've finalized on our usage of the
> Metawidget APIs.
> > > By the way,
> > > > > I'm the one responsible for the use (or abuse) of
> Metawidget in this manner.
> > > > >
> > > > > The rationale behind the use of Metawidget
> inspectors alone, is mostly because we want to allow users to modify the
> generated
> > > scaffold. One
> > > > of the
> > > > > examples thrown around was to enable users to
> generate master-detail views instead of the plain CRUD forms generated by
> Forge. Another
> > > driving
> > > > factor
> > > > > was the need to create or enable creation of
> scaffold generators for several JS frameworks including but not restricted
> to AngularJS,
> > > Backbone.js,
> > > > > Aerogear etc. Furthermore, there is also a
> possibility of users needing to bring in plugins and extensions to these
> frameworks, like
> > > Angular-UI or
> > > > > Backbone.Forms, since the base frameworks may not
> satisfy all needs. From my understanding of the Metawidget pipeline and
> it's use
> > in the
> > > Forge
> > > > Faces
> > > > > and (the earlier) Aerogear scaffold plugins, this
> would have been possible if a metawidget were created for every use case
> (one per
> > > framework, per
> > > > > widget-type). We attempted to bring in the use of
> templates written in a familiar templating langu!
> > > > > age (like Freemarker/Velocity/StringTemplate)
> into the scaffold generation phase to make it easier for users to modify
> the generated
> > > scaffold.
> > > > This
> > > > > is somewhat on the lines of what the Yeoman
> generators do.
> > > > >
> > > > > Thanks to the APIs you've made available for
> the Metawidget pipeline, the inspection results could be processed before
> feeding
> > them to the
> > > > > templates. Every scaffold plugin that could
> potentially be written, would more or less use this approach, with the sole
> difference
> > being
> > > in the
> > > > > contents of the templates themselves. I hope this
> explains why I used the Inspectors alone, and not the
> InspectionResultProcessors and
> > > the rest of
> > > > > the pipeline. The inspectors just fit in naturally
> into the Forge scaffold generation pipeline.
> > > > >
> > > > > Based on the above, I personally think that a
> FreemarkerWidget (or VelocityWidget, or StringTemplateWidget) would be
> something to
> > > investigate.
> > > > > This is of course a raw idea of mine, and I would
> like to see if it is possible to use such a metawidget in a type-safe
> manner with the
> > > ability to
> > > > > configure the templates that it would consume. I'm
> not sure if creating such a widget would deviate from the intention behind
> the
> > Metawidget
> > > > project.
> > > > >
> > > > > As a side note, I'd also like to point out that
> there has been interest in supporting various additional HTML5 form input
> types
> > (telephone
> > > > > numbers, URLs etc.) in the generated scaffold, and
> this would require extending the JPA/Bean Validation Inspectors in
> Metawidget.
> > > > >
> > > > > Best regards,
> > > > > Vineet
> > > > >
> > > > > PS: CC'ing the forge-dev list.
> > > > >
> > > > > ----- Original Message -----
> > > > > > From: "Richard Kennard" <
> richard at kennardconsulting.com <mailto:richard at kennardconsulting.com>
> > <mailto:richard at kennardconsulting.com <mailto:
> richard at kennardconsulting.com>> <mailto:richard at kennardconsulting.com
> > <mailto:richard at kennardconsulting.com>
> > > <mailto:richard at kennardconsulting.com <mailto:
> richard at kennardconsulting.com>>> <mailto:richard at kennardconsulting.com
> > <mailto:richard at kennardconsulting.com> <mailto:
> richard at kennardconsulting.com <mailto:richard at kennardconsulting.com>>
> > > > <mailto:richard at kennardconsulting.com <mailto:
> richard at kennardconsulting.com> <mailto:richard at kennardconsulting.com
> > <mailto:richard at kennardconsulting.com>>>>>
> > > > > > To: aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org> <mailto:aerogear-dev at lists.jboss.org
> > <mailto:aerogear-dev at lists.jboss.org>> <mailto:
> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
> > > <mailto:aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org>>> <mailto:aerogear-dev at lists.jboss.org
> > <mailto:aerogear-dev at lists.jboss.org> <mailto:
> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>>
> > > > <mailto:aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org> <mailto:aerogear-dev at lists.jboss.org
> > <mailto:aerogear-dev at lists.jboss.org>>>>
> > > > > > Sent: Thursday, February 21, 2013 5:17:29 AM
> > > > > > Subject: Re: [aerogear-dev] Aerogear Forge Plugin
> > > > > >
> > > > > > Seb,
> > > > > >
> > > > > > This looks very cool. I see you have used parts
> of Metawidget for
> > > > > > some of the implementation? I'd love to hear
> your thoughts on how it
> > > > > > went and/or any
> > > > > > changes you'd like me to make to Metawidget. For
> example:
> > > > > >
> > > > > > 1. You have some code in Html5Scaffold that
> processes the inspection
> > > > > > result returned by CompositeInspector. It does
> things like
> > > > > > 'Canonicalize all numerical
> > > > > > types in Java to "number" for HTML5 form input
> type support' and
> > > > > > 'Extract simple type name of the relationship
> types'. Was there a
> > > > > > reason you didn't factor
> > > > > > this into a Metawidget InspectionResultProcessor
> > > > > > (
> http://metawidget.org/doc/reference/en/html/ch02s03.html)?
> > > > > > Specifically BaseInspectionResultProcessor has
> > > > > > some methods to help?
> > > > > >
> > > > > > 2. You appear to be using FreeMarker templates
> rather than
> > > > > > Metawidget's WidgetBuilders, WidgetProcessors
> and Layouts (see the
> > > > > > existing Forge JSF scaffold,
> > > > > > Forge GWT scaffold, and Forge Spring scaffold).
> Could I ask what the
> > > > > > reasons were behind this?
> > > > > >
> > > > > > 3. I have recently implemented a pure
> client-side, pure run-time,
> > > > > > AngularJS version of Metawidget. If you were
> interested in a
> > > > > > non-static version of your
> > > > > > scaffold, perhaps you could give it a try?
> > > > > >
> http://blog.kennardconsulting.com/2013/01/metawidget-meets-jquery-ui-and-angularjs.html
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Richard.
> > > > > >
> > > > > > On 20/02/2013 11:49 PM, Jay Balunas wrote:
> > > > > > > Wow!!! Really awesome work guys!!!
> > > > > > >
> > > > > > > On Feb 15, 2013, at 11:15 AM, Sebastien Blanc
> wrote:
> > > > > > >
> > > > > > >> Hi all !
> > > > > > >> I'm pleased to announce that the first
> version of the Aerogear
> > > > > > >> Scaffold Plugin for forge is available !
> > > > > > >> It's still an alpha but thanks to the
> excellent work and help from
> > > > > > >> Vineet we have a working plugin :
> > > > > > >>
> > > > > > >> - CRUD Scaffolding based on your entities.
> > > > > > >> - One-to-one , many-to-one relation supported.
> > > > > > >> - AngularJS and bootstrap responsive based.
> > > > > > >> - Aerogear Pipe and Store used.
> > > > > > >>
> > > > > > >> There is still a lot to do but you can
> already play with it, a
> > > > > > >> quickstart is available here and you should
> be able to create
> > > > > > >> your first Aerogear App in
> > > > > > >> 5 minutes ;)
> https://gist.github.com/sebastienblanc/4961324
> > > > > > >>
> > > > > > >> An example of a generated application can
> also be found here :
> > > > > > >>
> https://github.com/sebastienblanc/scaffoldtester , please review
> > > > > > >> the generated code (at
> > > > > > >> least the JS and HTML) and report it to me
> and I will update the
> > > > > > >> templates accordingly.
> > > > > > >>
> > > > > > >> Next steps are :
> > > > > > >> - Integrate Search feature (using the
> DataStore filter facilities)
> > > > > > >> - Integrate Aerogear Pagination (although
> generic pagination is
> > > > > > >> present now)
> > > > > > >> - Integrate jQueryMobile (will probably be
> another plugin)
> > > > > > >>
> > > > > > >> Enjoy !
> > > > > > >>
> > > > > > >> Seb
> > > > > > >>
> > > > > > >>
> _______________________________________________
> > > > > > >> aerogear-dev mailing list
> > > > > > >> aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org> <mailto:aerogear-dev at lists.jboss.org
> > <mailto:aerogear-dev at lists.jboss.org>> <mailto:
> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
> > > <mailto:aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org>>> <mailto:aerogear-dev at lists.jboss.org
> > <mailto:aerogear-dev at lists.jboss.org> <mailto:
> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>>
> > > > <mailto:aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org> <mailto:aerogear-dev at lists.jboss.org
> > <mailto:aerogear-dev at lists.jboss.org>>>> <mailto:
> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
> > > <mailto:aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org>> <mailto:aerogear-dev at lists.jboss.org
> > <mailto:aerogear-dev at lists.jboss.org> <mailto:
> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>>>
> > > > <mailto:aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org> <mailto:aerogear-dev at lists.jboss.org
> > <mailto:aerogear-dev at lists.jboss.org>> <mailto:
> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
> > > <mailto:aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org>>>>>
> > > > > > >>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > aerogear-dev mailing list
> > > > > > > aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org> <mailto:aerogear-dev at lists.jboss.org
> > <mailto:aerogear-dev at lists.jboss.org>> <mailto:
> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
> > > <mailto:aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org>>> <mailto:aerogear-dev at lists.jboss.org
> > <mailto:aerogear-dev at lists.jboss.org> <mailto:
> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>>
> > > <mailto:aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org> <mailto:aerogear-dev at lists.jboss.org
> > <mailto:aerogear-dev at lists.jboss.org>>>>
> > > > > > >
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > >
> > > > > > _______________________________________________
> > > > > > aerogear-dev mailing list
> > > > > > aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org> <mailto:aerogear-dev at lists.jboss.org
> > <mailto:aerogear-dev at lists.jboss.org>> <mailto:
> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
> > > <mailto:aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org>>> <mailto:aerogear-dev at lists.jboss.org
> > <mailto:aerogear-dev at lists.jboss.org> <mailto:
> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>>
> > > <mailto:aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org> <mailto:aerogear-dev at lists.jboss.org
> > <mailto:aerogear-dev at lists.jboss.org>>>>
> > > > > >
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > aerogear-dev mailing list
> > > > > aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org> <mailto:aerogear-dev at lists.jboss.org
> > <mailto:aerogear-dev at lists.jboss.org>> <mailto:
> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
> > > <mailto:aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org>>> <mailto:aerogear-dev at lists.jboss.org
> > <mailto:aerogear-dev at lists.jboss.org> <mailto:
> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>>
> > > <mailto:aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org> <mailto:aerogear-dev at lists.jboss.org
> > <mailto:aerogear-dev at lists.jboss.org>>>>
> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > aerogear-dev mailing list
> > > > > aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org> <mailto:aerogear-dev at lists.jboss.org
> > <mailto:aerogear-dev at lists.jboss.org>> <mailto:
> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
> > <mailto:aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org>>>
> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org> <mailto:aerogear-dev at lists.jboss.org
> > <mailto:aerogear-dev at lists.jboss.org>> <mailto:
> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
> > <mailto:aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org>>>
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org> <mailto:aerogear-dev at lists.jboss.org<mailto:
> aerogear-dev at lists.jboss.org>>
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
> <mailto:aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org
> >>
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130301/5f2fbf17/attachment-0001.html
More information about the aerogear-dev
mailing list