GrailsUI is Now an Unsupported Plugin

[Matthew Taylor-2]

Thank you to all users and contributors of GrailsUI. I'll still watch the mailings lists for questions. Lots of details about this decision on my blog:

http://rhyolight.posterous.com/grailsui-is-now-an-unsupported-plugin

Respectfully,
--
matthew taylor
yahoo! front-end engineer
[hidden email]

[Daniel Honig]

  This is probably the right decision.  Given the 1.0 project is now close to two full years old.  There is definitely a need for a framework that integrates easily with Grails in an easy to use way.   Over the past two years I've come to see that to do a good job at this for a GrailsUI 2.0 is potentially a pretty large effort.  One would need to ask if GrailsUI 2.0 is fundamentally a simple widget framework or a more complete RIA layer such as what Vaadin or GWT bring to the table.   The original GrailsUI had support from G2One/SpringSource and without some kind of funding I think it would be very hard to create something that offers something that is significantly better than what can be achieved through GWT based frameworks or JQuery.
  I also don't want this to take away from what was accomplished.  The original vision concept for Grails UI was to be a simple widget library that solved the most common problems with respect to the 80/20 rule.  We wanted a way to keep what should be simple, easy to do, while allowing the ability to leverage the widgets for more complex problems when needed.   I would like to commend Matt on doing a stellar job of not only achieving those goals but for providing great support ( mostly by himself.).  
  If your AJAX requirements are simple to moderate and your interested in leveraging the excellent YUI 2.X widgets then I would say that Grails UI still is a viable option.  Beyond that, if there is interest in a next generation UI framework that fits perfectly with grails then I'd love to hear what people are thinking.  Perhaps we can get some good discussion on the group Matt has already started: http://groups.google.com/group/grailsui-dev/web/grailsui-2-0-planning-page

On Tue, Jul 27, 2010 at 2:16 PM, Matthew Taylor <[hidden email]> wrote:

Thank you to all users and contributors of GrailsUI. I'll still watch the mailings lists for questions. Lots of details about this decision on my blog:

http://rhyolight.posterous.com/grailsui-is-now-an-unsupported-plugin

Respectfully,
--
matthew taylor
yahoo! front-end engineer
[hidden email]

[Jason Davis]

I never really saw the point in the ui plugin. Either way I have to
write out a big tag/function, and I find the JS more readable and more
standard. Seeing as RIA is all the rage, as is JS, seems a poor
decision to learn a grails wrapper rather than the JS apis themselves.

.02,
Jason

On Tue, Jul 27, 2010 at 12:38 PM, Daniel Honig <[hidden email]> wrote:

>   This is probably the right decision.  Given the 1.0 project is now close
> to two full years old.  There is definitely a need for a framework that
> integrates easily with Grails in an easy to use way.   Over the past two
> years I've come to see that to do a good job at this for a GrailsUI 2.0 is
> potentially a pretty large effort.  One would need to ask if GrailsUI 2.0 is
> fundamentally a simple widget framework or a more complete RIA layer such as
> what Vaadin or GWT bring to the table.   The original GrailsUI had support
> from G2One/SpringSource and without some kind of funding I think it would be
> very hard to create something that offers something that is significantly
> better than what can be achieved through GWT based frameworks or JQuery.
>   I also don't want this to take away from what was accomplished.  The
> original vision concept for Grails UI was to be a simple widget library that
> solved the most common problems with respect to the 80/20 rule.  We wanted a
> way to keep what should be simple, easy to do, while allowing the ability to
> leverage the widgets for more complex problems when needed.   I would like
> to commend Matt on doing a stellar job of not only achieving those goals but
> for providing great support ( mostly by himself.).
>   If your AJAX requirements are simple to moderate and your interested in
> leveraging the excellent YUI 2.X widgets then I would say that Grails UI
> still is a viable option.  Beyond that, if there is interest in a next
> generation UI framework that fits perfectly with grails then I'd love to
> hear what people are thinking.  Perhaps we can get some good discussion on
> the group Matt has already started:
> http://groups.google.com/group/grailsui-dev/web/grailsui-2-0-planning-page
>
> On Tue, Jul 27, 2010 at 2:16 PM, Matthew Taylor <[hidden email]> wrote:
>>
>> Thank you to all users and contributors of GrailsUI. I'll still watch the
>> mailings lists for questions. Lots of details about this decision on my
>> blog:
>> http://rhyolight.posterous.com/grailsui-is-now-an-unsupported-plugin
>>
>> Respectfully,
>> --
>> matthew taylor
>> yahoo! front-end engineer
>> [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[johnrellis]

Matthew,

Thanks for all your Grails UI help over the past couple of years.  You have definitely helped me out more than a couple of times and it is hugely appreciated.

I am looking forward to see what the future will bring in the Grails Front End debate.

Thanks,

John

On Tue, Jul 27, 2010 at 11:58 PM, Jason Davis <[hidden email]> wrote:

I never really saw the point in the ui plugin. Either way I have to
write out a big tag/function, and I find the JS more readable and more
standard. Seeing as RIA is all the rage, as is JS, seems a poor
decision to learn a grails wrapper rather than the JS apis themselves.

.02,
Jason

On Tue, Jul 27, 2010 at 12:38 PM, Daniel Honig <[hidden email]> wrote:
>   This is probably the right decision.  Given the 1.0 project is now close
> to two full years old.  There is definitely a need for a framework that
> integrates easily with Grails in an easy to use way.   Over the past two
> years I've come to see that to do a good job at this for a GrailsUI 2.0 is
> potentially a pretty large effort.  One would need to ask if GrailsUI 2.0 is
> fundamentally a simple widget framework or a more complete RIA layer such as
> what Vaadin or GWT bring to the table.   The original GrailsUI had support
> from G2One/SpringSource and without some kind of funding I think it would be
> very hard to create something that offers something that is significantly
> better than what can be achieved through GWT based frameworks or JQuery.
>   I also don't want this to take away from what was accomplished.  The
> original vision concept for Grails UI was to be a simple widget library that
> solved the most common problems with respect to the 80/20 rule.  We wanted a
> way to keep what should be simple, easy to do, while allowing the ability to
> leverage the widgets for more complex problems when needed.   I would like
> to commend Matt on doing a stellar job of not only achieving those goals but
> for providing great support ( mostly by himself.).
>   If your AJAX requirements are simple to moderate and your interested in
> leveraging the excellent YUI 2.X widgets then I would say that Grails UI
> still is a viable option.  Beyond that, if there is interest in a next
> generation UI framework that fits perfectly with grails then I'd love to
> hear what people are thinking.  Perhaps we can get some good discussion on
> the group Matt has already started:
> http://groups.google.com/group/grailsui-dev/web/grailsui-2-0-planning-page
>
> On Tue, Jul 27, 2010 at 2:16 PM, Matthew Taylor <[hidden email]> wrote:
>>
>> Thank you to all users and contributors of GrailsUI. I'll still watch the
>> mailings lists for questions. Lots of details about this decision on my
>> blog:
>> http://rhyolight.posterous.com/grailsui-is-now-an-unsupported-plugin
>>
>> Respectfully,
>> --
>> matthew taylor
>> yahoo! front-end engineer
>> [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Marc Palmer Local]

On 28 Jul 2010, at 10:00, John Rellis wrote:

> Matthew,
>
> Thanks for all your Grails UI help over the past couple of years.  You have definitely helped me out more than a couple of times and it is hugely appreciated.
>
> I am looking forward to see what the future will bring in the Grails Front End debate.

I personally think that we have a lot more groundwork to do in Grails before worrying about "smart UI layer" stuff.

E.g. we have current lack of:

* Unified (core) way to include JS resources e.g. jQuery once and only once in a page
   - Who wants to use a GSP page from a plugin that pulls in the same JS resource again into <head>?

* No dependency management for JS/CSS resources (unless they are put into plugins as I proposed and worked on with jquery and jquery-ui)
   - Who wants to use plugins that rely on disparate versions of JS/CSS libraries? Thanks for the bloat & slow downloads! Even with the plugin approach, all Grails plugins need to depend on these plugins and stop including their own resources - e.g. Weceem has switched to this model

* No smart solution for automatic minifying/merging of JS/CSS resource files provided by the app and plugins
   - Its no fun if adding a bunch plugins to your app means you need to configure a bunch of manual stuff controlling the minifying or not of them

* No mechanism to centralise inline JS fragments of pages into a separate unified JS resource per page, served by a controller (E.S.P. plugin proposoal of yore)
   - without this pages with lots of JS are much bigger and largely uncacheable

I think once we have those basics covered, then we can look at maybe some high-level smarts - but I maintain that I see limited use for a high level UI library that has a selling point of "you can switch between underlying JS framework used". The gain is marginal. Be opinionated, just build dedicated ui tag lib plugins for each JS framework that is popular - where it makes sense.

Although I am of the opinion also that this stuff is easy and better coded direct. You will always have to.

There *might* be a strong case for a dedicated set of "live data-bound widgets" based on a specific JS library e.g. jQuery/Ui. I'm not sure people really want that stuff this much these days do they, even in the enterprise? It was all the rage when N-tier was the "next big thing" but...

Marc
~ ~ ~
Marc Palmer
Blog         > http://www.anyware.co.uk
Twitter      > http://twitter.com/wangjammer5
Grails Rocks > http://www.grailsrocks.com







---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Björn Wilmsmann-2]

 I agree :)

On 28 July 2010 22:33, Marc Palmer <[hidden email]> wrote:

> I personally think that we have a lot more groundwork to do in Grails before worrying about "smart UI layer" stuff.
>
> E.g. we have current lack of:
>
> * Unified (core) way to include JS resources e.g. jQuery once and only once in a page
>   - Who wants to use a GSP page from a plugin that pulls in the same JS resource again into <head>?
>
> * No dependency management for JS/CSS resources (unless they are put into plugins as I proposed and worked on with jquery and jquery-ui)
>   - Who wants to use plugins that rely on disparate versions of JS/CSS libraries? Thanks for the bloat & slow downloads! Even with the plugin approach, all Grails plugins need to depend on these plugins and stop including their own resources - e.g. Weceem has switched to this model
>
> * No smart solution for automatic minifying/merging of JS/CSS resource files provided by the app and plugins
>   - Its no fun if adding a bunch plugins to your app means you need to configure a bunch of manual stuff controlling the minifying or not of them
>
> * No mechanism to centralise inline JS fragments of pages into a separate unified JS resource per page, served by a controller (E.S.P. plugin proposoal of yore)
>   - without this pages with lots of JS are much bigger and largely uncacheable

--
Best regards,
Björn Wilmsmann

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Graeme Rocher-3]

Would be good if you could write a proposal on how you would like the below to work

Cheers

On 28 Jul 2010, at 22:33, Marc Palmer wrote:

>
> On 28 Jul 2010, at 10:00, John Rellis wrote:
>
>> Matthew,
>>
>> Thanks for all your Grails UI help over the past couple of years.  You have definitely helped me out more than a couple of times and it is hugely appreciated.
>>
>> I am looking forward to see what the future will bring in the Grails Front End debate.
>
> I personally think that we have a lot more groundwork to do in Grails before worrying about "smart UI layer" stuff.
>
> E.g. we have current lack of:
>
> * Unified (core) way to include JS resources e.g. jQuery once and only once in a page
>   - Who wants to use a GSP page from a plugin that pulls in the same JS resource again into <head>?
>
> * No dependency management for JS/CSS resources (unless they are put into plugins as I proposed and worked on with jquery and jquery-ui)
>   - Who wants to use plugins that rely on disparate versions of JS/CSS libraries? Thanks for the bloat & slow downloads! Even with the plugin approach, all Grails plugins need to depend on these plugins and stop including their own resources - e.g. Weceem has switched to this model
>
> * No smart solution for automatic minifying/merging of JS/CSS resource files provided by the app and plugins
>   - Its no fun if adding a bunch plugins to your app means you need to configure a bunch of manual stuff controlling the minifying or not of them
>
> * No mechanism to centralise inline JS fragments of pages into a separate unified JS resource per page, served by a controller (E.S.P. plugin proposoal of yore)
>   - without this pages with lots of JS are much bigger and largely uncacheable
>
> I think once we have those basics covered, then we can look at maybe some high-level smarts - but I maintain that I see limited use for a high level UI library that has a selling point of "you can switch between underlying JS framework used". The gain is marginal. Be opinionated, just build dedicated ui tag lib plugins for each JS framework that is popular - where it makes sense.
>
> Although I am of the opinion also that this stuff is easy and better coded direct. You will always have to.
>
> There *might* be a strong case for a dedicated set of "live data-bound widgets" based on a specific JS library e.g. jQuery/Ui. I'm not sure people really want that stuff this much these days do they, even in the enterprise? It was all the rage when N-tier was the "next big thing" but...
>
> Marc
> ~ ~ ~
> Marc Palmer
> Blog         > http://www.anyware.co.uk
> Twitter      > http://twitter.com/wangjammer5
> Grails Rocks > http://www.grailsrocks.com
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Marc Palmer Local]

On 29 Jul 2010, at 08:58, Graeme Rocher wrote:

> Would be good if you could write a proposal on how you would like the below to work

Will do. I did write a blog on the "E.S.P." aspect some time ago and Matt Taylor and I started work on a prototype to shakedown the issues with it.

Marc


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Matthew Taylor-2]

I had started on something, it is a bit dated: http://github.com/rhyolight/grails-esp

On Thu, Jul 29, 2010 at 2:24 AM, Marc Palmer <[hidden email]> wrote:

On 29 Jul 2010, at 08:58, Graeme Rocher wrote:

> Would be good if you could write a proposal on how you would like the below to work

Will do. I did write a blog on the "E.S.P." aspect some time ago and Matt Taylor and I started work on a prototype to shakedown the issues with it.

Marc

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

--
matthew taylor
yahoo! front-end engineer
[hidden email]

[haah]

thanks matt for all the support that you have given
really appreaciate it a lot

[fabien7474]

I definitely agree.  

Also I would also add:
* a simple mechanism for storing resources like JS and CSS in a domain server different from the grails webapp server. This is a common practice for web application (see stackoverflow website for instance). And without a unified mechanism for plugins, it becomes a nightmare to migrate plugin resources (like JS) to another domain.

Marc Palmer Local wrote

E.g. we have current lack of:

* Unified (core) way to include JS resources e.g. jQuery once and only once in a page
   - Who wants to use a GSP page from a plugin that pulls in the same JS resource again into <head>?

* No dependency management for JS/CSS resources (unless they are put into plugins as I proposed and worked on with jquery and jquery-ui)
   - Who wants to use plugins that rely on disparate versions of JS/CSS libraries? Thanks for the bloat & slow downloads! Even with the plugin approach, all Grails plugins need to depend on these plugins and stop including their own resources - e.g. Weceem has switched to this model

* No smart solution for automatic minifying/merging of JS/CSS resource files provided by the app and plugins
   - Its no fun if adding a bunch plugins to your app means you need to configure a bunch of manual stuff controlling the minifying or not of them

* No mechanism to centralise inline JS fragments of pages into a separate unified JS resource per page, served by a controller (E.S.P. plugin proposoal of yore)
   - without this pages with lots of JS are much bigger and largely uncacheable

Marc