Kevin Hinners | 1 Jul 03:12 2005
Picon

RE: Grails: JSF Components?

I disagree with these statements.

The only component that JSF requires JavaScript for (at least in the Sun
Reference Implementation) is the commandLink. And then it only uses
simple, cross-browser supported JavaScript. AJAX (Asynchronous
JavaScript and XML), by its own definition, heavily relies on JavaScript
for display. I can't speak for its cross-browser support, however.

JSF is not request/response-based, but state-based using a hierarchical
component tree representing your GUI controls on the server. It does
borrow heavily on the Swing event programming model, but that is a good
thing. It allows actions on one control to propagate to other controls
using ActionListener methods, among other things.

JSF is wholly suited for the UI or view layer. As a framework, it does
have its limitations admittedly. But there are many solutions to that
problem. I just attended JavaOne and sat in on sessions regarding how
JSF can interoperate nicely with both Shale and Spring. So use those
frameworks if JSF alone is not sufficient for your purposes.

Kevin Hinners
Senior Technical Analyst

FedEx Services
350 Spectrum Loop
Colorado Springs, CO 80921
719-484-2303
kevin.hinners@...

-----Original Message-----
(Continue reading)

Jeremy Rayner | 1 Jul 06:32 2005
Picon

James Gosling article...

Hi,
  Just a quick pointer to another article... 
James Gosling gives some thoughts about Groovy and Java in his most
recent interview...
http://news.zdnet.com/2102-9593_22-5768605.html?tag=printthis

jez.
--

-- 
http://javanicus.com/blog2

Jeremy Rayner | 1 Jul 08:55 2005
Picon

Re: James Gosling article...

>  Just a quick pointer to another article...
> James Gosling gives some thoughts about Groovy and Java in his most
> recent interview...
> http://news.zdnet.com/2102-9593_22-5768605.html?tag=printthis

The James Gosling article has been slashdotted...
http://developers.slashdot.org/developers/05/07/01/0018203.shtml

So there are some comments about Groovy from the slashdot crowd...
http://developers.slashdot.org/comments.pl?sid=154501&cid=12956728
http://developers.slashdot.org/comments.pl?sid=154501&cid=12956932

Cheers
jez.
--

-- 
http://javanicus.com/blog2

netsql | 1 Jul 10:57 2005

Re: James Gosling article...

good link.

It be interesting which one is more scaleable: J2EE/EJB vs Collections 
processing + SQL on Groovy side (+ some simple Soft Map Cache). My 
feeling is that Groovy would prove more scaleable.

.V

Jeremy Rayner wrote:
> Hi,
>   Just a quick pointer to another article... 
> James Gosling gives some thoughts about Groovy and Java in his most
> recent interview...
> http://news.zdnet.com/2102-9593_22-5768605.html?tag=printthis
> 
> jez.

Graham O'Regan | 1 Jul 11:01 2005

Re: Re: [groovy-dev] grails: coding conventions write up

I thought actions in WW were per-request, a throw-away object so thread-safety wasn't an issue? Or are you referring to the servlet as the controller?

Some great ideas coming up here btw ;)

Steven Devijver wrote:
On 6/30/05, Guillaume Laforge <glaforge-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
On 30/06/05, Graeme Rocher <graeme.rocher-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
[...] Notice how I have not exposed the request and response objects and their complexities by default. There should be convenience maps automatically available like from the super class: params.myparam session.myprop
Hmmm, with dependency injection, we could simply declare: <at> Property params And tada, the IoC container injects the params directly?
Unfortunately that approach is not thread-safe. Controllers are meant to be singletons so parameters have to be passed along as parameters to methods or closures to ensure thread-safety. One thing I have been thinking about is a good Groovy abstraction for the request and response interfaces. Maps seem nice but then we only have the state without the behavior. But maps support in Groovy is nice so we should probably merge the Map interface with the HttpServletRequest and HttpServletResponse interfaces. If anyone wants to take a shot a this please feel free to do so.

-- Graham O'Regan Senior Developer Ellison Brookes w: http://www.ellisonbrookes.com The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Ellison Brookes is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt.
Graham O'Regan | 1 Jul 11:06 2005

Re: Re: [groovy-dev] grails: coding conventions write up

I think the idea of a map of parameters is a really bad way to go, it's 
better to have a strongly typed object (like strut's actionForm) so you 
know *exactly* what parameters you are accepting and can validate their 
type and content before processing.

Maps of attributes is more acceptible tho, like RequestMap, SessionMap 
and ApplicationMap which *only* reference maps of objects that the 
application has created rather than opening the map to parameters that 
the user can create.

Christof Vollrath wrote:

> Hi Steve,
> to handle request parameters in GvTags I invented a DynaForm.
> This DynaForm extends a map by allowing subforms and arrays.
> So if a HTTP request parameter is named like: form.subform.array[5].name
> the request can be parsed and several DynaForm objects will be 
> created, so that
> the field can be accessed using the same expressions as the parameter 
> name.
> This makes it easy to have subforms and tables in a form.
>
> By,
> tof
>
> Steven Devijver wrote:
>
>>
>> One thing I have been thinking about is a good Groovy abstraction for
>> the request and response interfaces. Maps seem nice but then we only
>> have the state without the behavior. But maps support in Groovy is
>> nice so we should probably merge the Map interface with the
>> HttpServletRequest and HttpServletResponse interfaces.
>>
>> If anyone wants to take a shot a this please feel free to do so.
>>
>>  
>>
>
>
>

-- 

Graham O'Regan

Senior Developer
Ellison Brookes

m: 07971 993 726
e: graham.oregan@...
w: http://www.ellisonbrookes.com

The information contained in this communication is intended solely for the use of the individual or entity
to whom it is addressed and others authorized to receive it. It may contain confidential or legally
privileged information. If you are not the intended recipient you are hereby notified that any
disclosure, copying, distribution or taking any action in reliance on the contents of this information
is strictly prohibited and may be unlawful. If you have received this communication in error, please
notify us immediately by responding to this email and then delete it from your system. Ellison Brookes is
neither liable for the proper and complete transmission of the information contained in this
communication nor for any delay in its receipt.

Jochen Theodorou | 1 Jul 11:09 2005
Picon

the most annoying Groovy Bug?

Hi Groovy Users,

lately I asked myself "what is the most annoying bug in groovy?" You may 
know that you can vote for a jira issue. I want to invite you to harvest 
JIRA for an issue or to fill a new issue and vote for it. We will try to 
fix the bug with the most votes until the next release.

bye blackdrag

Graeme Rocher | 1 Jul 11:18 2005
Picon

Re: Re: [groovy-dev] grails: coding conventions write up

Graham,

Yes they are threadsafe, I think what Steven is emplying is that in
Grails the Controller take more responsibility than some web
frameworks for creating command objects and forwarding to Service
objects.

Controllers should really be singleton, which presents a thread safety issue..

The problem with this, I believe, is that it makes it more complex
than necessary and is not necessarily as simple as ROR (which is what
Grails will be competing with).

Graeme

On 7/1/05, Graham O'Regan <graham.oregan@...> wrote:
>  I thought actions in WW were per-request, a throw-away object so
> thread-safety wasn't an issue? Or are you referring to the servlet as the
> controller?
>  
>  Some great ideas coming up here btw ;)
> 
>  
>  Steven Devijver wrote: 
>  On 6/30/05, Guillaume Laforge <glaforge@...> wrote:
>  
>  
>  On 30/06/05, Graeme Rocher <graeme.rocher@...> wrote:
>  
>  
>  [...]
> Notice how I have not exposed the request and response objects and
> their complexities by default. There should be convenience maps
> automatically available like from the super class:
> 
> params.myparam
> session.myprop
>  
>  Hmmm, with dependency injection, we could simply declare:
> 
>  <at> Property params
> 
> And tada, the IoC container injects the params directly?
> 
>  
>  Unfortunately that approach is not thread-safe. Controllers are meant
> to be singletons so parameters have to be passed along as parameters
> to methods or closures to ensure thread-safety.
> 
> One thing I have been thinking about is a good Groovy abstraction for
> the request and response interfaces. Maps seem nice but then we only
> have the state without the behavior. But maps support in Groovy is
> nice so we should probably merge the Map interface with the
> HttpServletRequest and HttpServletResponse interfaces.
> 
> If anyone wants to take a shot a this please feel free to do so.
> 
> 
>  
>  
>  -- 
> 
> 
> Graham O'Regan
> 
> Senior Developer
> Ellison Brookes
> 
> w: http://www.ellisonbrookes.com
> 
> 
> The information contained in this communication is intended solely for the
> use of the individual or entity to whom it is addressed and others
> authorized to receive it. It may contain confidential or legally privileged
> information. If you are not the intended recipient you are hereby notified
> that any disclosure, copying, distribution or taking any action in reliance
> on the contents of this information is strictly prohibited and may be
> unlawful. If you have received this communication in error, please notify us
> immediately by responding to this email and then delete it from your system.
> Ellison Brookes is neither liable for the proper and complete transmission
> of the information contained in this communication nor for any delay in its
> receipt.
>

Graeme Rocher | 1 Jul 11:22 2005
Picon

Re: Re: [groovy-dev] grails: coding conventions write up

On 7/1/05, Graham O'Regan <graham.oregan@...> wrote:
> I think the idea of a map of parameters is a really bad way to go, it's
> better to have a strongly typed object (like strut's actionForm) so you
> know *exactly* what parameters you are accepting and can validate their
> type and content before processing.
> 
When has "strongly typed" been a major consideration in scripting languages?
And why does using a Map preclude validation? You can still validate
the Map just as you would the request object.

> Maps of attributes is more acceptible tho, like RequestMap, SessionMap
> and ApplicationMap which *only* reference maps of objects that the
> application has created rather than opening the map to parameters that
> the user can create.
> 
> Christof Vollrath wrote:
> 
> > Hi Steve,
> > to handle request parameters in GvTags I invented a DynaForm.
> > This DynaForm extends a map by allowing subforms and arrays.
> > So if a HTTP request parameter is named like: form.subform.array[5].name
> > the request can be parsed and several DynaForm objects will be
> > created, so that
> > the field can be accessed using the same expressions as the parameter
> > name.
> > This makes it easy to have subforms and tables in a form.
> >
> > By,
> > tof
> >
> > Steven Devijver wrote:
> >
> >>
> >> One thing I have been thinking about is a good Groovy abstraction for
> >> the request and response interfaces. Maps seem nice but then we only
> >> have the state without the behavior. But maps support in Groovy is
> >> nice so we should probably merge the Map interface with the
> >> HttpServletRequest and HttpServletResponse interfaces.
> >>
> >> If anyone wants to take a shot a this please feel free to do so.
> >>
> >>
> >>
> >
> >
> >
> 
> --
> 
> 
> Graham O'Regan
> 
> Senior Developer
> Ellison Brookes
> 
> m: 07971 993 726
> e: graham.oregan@...
> w: http://www.ellisonbrookes.com
> 
> 
> The information contained in this communication is intended solely for the use of the individual or
entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally
privileged information. If you are not the intended recipient you are hereby notified that any
disclosure, copying, distribution or taking any action in reliance on the contents of this information
is strictly prohibited and may be unlawful. If you have received this communication in error, please
notify us immediately by responding to this email and then delete it from your system. Ellison Brookes is
neither liable for the proper and complete transmission of the information contained in this
communication nor for any delay in its receipt.
> 
>

Graham O'Regan | 1 Jul 12:14 2005

Re: Re: [groovy-dev] grails: coding conventions write up

lol - good point!

My point is that you shouldn't accept all parameters, lump them into a map and chuck them to the application. I might be complicating things by looking at the mistake the struts developers made by including maps. In a purely scripting, dynamic environment, it may be more acceptible.

I need to think in a more groovy manner and less about typing I suppose :$

Graeme Rocher wrote:
On 7/1/05, Graham O'Regan <graham.oregan-hLP5QRf/WPkaAEmSxgGLmNBPR1lH4CV8@public.gmane.org> wrote:
I think the idea of a map of parameters is a really bad way to go, it's better to have a strongly typed object (like strut's actionForm) so you know *exactly* what parameters you are accepting and can validate their type and content before processing.
When has "strongly typed" been a major consideration in scripting languages? And why does using a Map preclude validation? You can still validate the Map just as you would the request object.
Maps of attributes is more acceptible tho, like RequestMap, SessionMap and ApplicationMap which *only* reference maps of objects that the application has created rather than opening the map to parameters that the user can create. Christof Vollrath wrote:
Hi Steve, to handle request parameters in GvTags I invented a DynaForm. This DynaForm extends a map by allowing subforms and arrays. So if a HTTP request parameter is named like: form.subform.array[5].name the request can be parsed and several DynaForm objects will be created, so that the field can be accessed using the same expressions as the parameter name. This makes it easy to have subforms and tables in a form. By, tof Steven Devijver wrote:
One thing I have been thinking about is a good Groovy abstraction for the request and response interfaces. Maps seem nice but then we only have the state without the behavior. But maps support in Groovy is nice so we should probably merge the Map interface with the HttpServletRequest and HttpServletResponse interfaces. If anyone wants to take a shot a this please feel free to do so.
-- Graham O'Regan Senior Developer Ellison Brookes m: 07971 993 726 e: graham.oregan-hLP5QRf/WPkaAEmSxgGLmNBPR1lH4CV8@public.gmane.org w: http://www.ellisonbrookes.com The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Ellison Brookes is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt.

-- Graham O'Regan Senior Developer Ellison Brookes w: http://www.ellisonbrookes.com The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Ellison Brookes is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt.

Gmane