[ringojs] Response helpers

[George Moschovitis]

I would like to propose that we make Ringo's Response helpers
compatible with Jack's, ie switch from:

var RESPONSE = require("ringo/webapp/response");
return RESPONSE.redirectResponse("/");
return RESPONSE.notFoundResponse();

to

var Response = require("ringo/webapp/response").Response;
return Response.redirect("/");
return Response.notFound();

what do you think? If you agree, I can provide the patch.

-g.

--
You received this message because you are subscribed to the Google Groups "RingoJS" group.
To post to this group, send email to rin...@googlegroups.com.
To unsubscribe from this group, send email to ringojs+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ringojs?hl=en.

[Hannes Wallnoefer]

2010/5/21 George Moschovitis <george.mo...@gmail.com>:

> I would like to propose that we make Ringo's Response helpers
> compatible with Jack's, ie switch from:
>
> var RESPONSE = require("ringo/webapp/response");
> return RESPONSE.redirectResponse("/");
> return RESPONSE.notFoundResponse();
>
> to
>
> var Response = require("ringo/webapp/response").Response;
> return Response.redirect("/");
> return Response.notFound();
>
> what do you think? If you agree, I can provide the patch.

+1 from my side. I prefer the static Response methods to the top level exports.

Hannes

[Simon Oberhammer]

> var Response = require("ringo/webapp/response").Response;
> return Response.redirect("/");
> return Response.notFound();
>
> what do you think? If you agree, I can provide the patch.

i like the shorter redirect() versus redirectResponse.

but - and maybe that's just me - i don't like attaching static
functions to a constructor. i see this:

return new Response()

then i'd expect

return (new Response()).redirect("/");

simon

[Hannes Wallnoefer]

2010/5/21 Simon Oberhammer <si...@nekapuzer.at>:

>> var Response = require("ringo/webapp/response").Response;
>> return Response.redirect("/");
>> return Response.notFound();
>>
>> what do you think? If you agree, I can provide the patch.
>
> i like the shorter redirect() versus redirectResponse.
>
> but - and maybe that's just me - i don't like attaching static
> functions to a constructor. i see this:
>
>   return new Response()
>
> then i'd expect
>
>   return (new Response()).redirect("/");

Why? I think having static methods that return an instance of what
they're hanging on is pretty good style. Why should you have to create
a response object just to create and return another one?

Hannes

[Simon Oberhammer]

> Why? I think having static methods that return an instance of what
> they're hanging on is pretty good style. Why should you have to create
> a response object just to create and return another one?

i didn't mean to say (new Response()).redirect() is good, i was just
happy with the toplevel exports.

but both response.Response.redirect and response.redirect are better
then response.redirectResponse

[Robert Thurnher]

On 21 May 2010 11:25, Hannes Wallnoefer <han...@helma.at> wrote:
> 2010/5/21 George  Moschovitis <george.mo...@gmail.com>:
>> I would like to propose that we make Ringo's Response helpers
>> compatible with Jack's, ie switch from:
>>
>> var RESPONSE = require("ringo/webapp/response");
>> return RESPONSE.redirectResponse("/");
>> return RESPONSE.notFoundResponse();
>>
>> to
>>
>> var Response = require("ringo/webapp/response").Response;
>> return Response.redirect("/");
>> return Response.notFound();
>>
>> what do you think? If you agree, I can provide the patch.
>
> +1 from my side. I prefer the static Response methods to the top level exports.

+1 from my side as well (I agree, this would be a further improvement there).

-- Robi

[Robert Thurnher]

On 21 May 2010 11:25, Hannes Wallnoefer <han...@helma.at> wrote:

> 2010/5/21 George  Moschovitis <george.mo...@gmail.com>:
>> I would like to propose that we make Ringo's Response helpers
>> compatible with Jack's, ie switch from:
>>
>> var RESPONSE = require("ringo/webapp/response");
>> return RESPONSE.redirectResponse("/");
>> return RESPONSE.notFoundResponse();
>>
>> to
>>
>> var Response = require("ringo/webapp/response").Response;
>> return Response.redirect("/");
>> return Response.notFound();
>>
>> what do you think? If you agree, I can provide the patch.
>
> +1 from my side. I prefer the static Response methods to the top level exports.

FYI, here's a patch for this:
http://github.com/robi42/ringojs/compare/response-refactoring

BTW, while refactoring also got rid of the implicit skin resource
relative path resolution magic.

Feedback welcome.

-- Robi

[Hannes Wallnoefer]

2010/8/21 Robert Thurnher <r.thu...@gmail.com>:

Thanks! I haven't looked at it yet, but I'm very glad we didn't
release 0.6 this past week.

Hannes

> Feedback welcome.
>
> -- Robi

[George Moschovitis]

looks good :)

-g.

--
http://www.gmosx.com/blog
http://www.appenginejs.org

[Hannes Wallnoefer]

On Aug 21, 6:23 pm, Robert Thurnher <r.thurn...@gmail.com> wrote:
> On 21 May 2010 11:25, Hannes Wallnoefer <han...@helma.at> wrote:
>
>
>

> > 2010/5/21 George  Moschovitis <george.moschovi...@gmail.com>:

> >> I would like to propose that we make Ringo's Response helpers
> >> compatible with Jack's, ie switch from:
>
> >> var RESPONSE = require("ringo/webapp/response");
> >> return RESPONSE.redirectResponse("/");
> >> return RESPONSE.notFoundResponse();
>
> >> to
>
> >> var Response = require("ringo/webapp/response").Response;
> >> return Response.redirect("/");
> >> return Response.notFound();
>
> >> what do you think? If you agree, I can provide the patch.
>
> > +1 from my side. I prefer the static Response methods to the top level exports.
>
> FYI, here's a patch for this:http://github.com/robi42/ringojs/compare/response-refactoring
>
> BTW, while refactoring also got rid of the implicit skin resource
> relative path resolution magic.
>
> Feedback welcome.

The module.directory + path pattern once more reminded me we should
introduce module.resolve(path) or module.resource(path) for locating
resources relative to a module, as has been proposed on CommonJS I
think multiple times.

http://groups.google.com/group/commonjs/browse_frm/thread/a6fa11983eea9196/275d849e4cc57b88

What do you think?

Hannes

> -- Robi

[Robert Thurnher]

+1 for such a `module.resolve(path)` (`resolve` name making intended
usage a bit clearer than `resource`, IMHO; but would be fine with any
of the two).

-- Robi

> Hannes
>
>> -- Robi
>

--
http://robert42.com/

[Robert Thurnher]

On 22 August 2010 07:17, George Moschovitis
<george.mo...@gmail.com> wrote:
> looks good :)

Thanks. :)

-- Robi

> -g.
>

[George Moschovitis]

>
> The module.directory + path pattern once more reminded me we should
> introduce module.resolve(path) or module.resource(path) for locating
> resources relative to a module, as has been proposed on CommonJS I
> think multiple times.
>
> http://groups.google.com/group/commonjs/browse_frm/thread/a6fa11983eea9196/275d849e4cc57b88
>
> What do you think?

+1 for such a `module.resolve(path)` (`resolve` name making intended
usage a bit clearer than `resource`, IMHO; but would be fine with any
of the two).

 i also prefer module.resolve()

-g.

[Hannes Wallnoefer]

On Aug 22, 5:47 pm, George Moschovitis <george.moschovi...@gmail.com>
wrote:

> > > The module.directory + path pattern once more reminded me we should
> > > introduce module.resolve(path) or module.resource(path) for locating
> > > resources relative to a module, as has been proposed on CommonJS I
> > > think multiple times.
>

> >http://groups.google.com/group/commonjs/browse_frm/thread/a6fa11983ee...

>
> > > What do you think?
>
> > +1 for such a `module.resolve(path)` (`resolve` name making intended
> > usage a bit clearer than `resource`, IMHO; but would be fine with any
> > of the two).
>
>  i also prefer module.resolve()

The problem with this is we can't just resolve to an absolute path
string. Modules can live in any Ringo repository/resource
implementation, including zip files and webapp resources. Simply
returning an absolute path and assuming it is a file won't work. For
this reason, the response-refactoring branch won't work on google app
engine.

So module.resolve() either has to return a resource or a resource path
(which would be a path relative to the repository root), or maybe a
URI. Maybe we also need to fix module.path for modules loaded from
webapp resources. In any case, there's more thinking and experimenting
to do.

Hannes

> -g.
>
> --http://www.gmosx.com/bloghttp://www.appenginejs.org

[James Cook]

While you guys are discussing this, if any progress can be made to auto-include the resources from a jar on the classpath would be just great. (Just like RingoJS does with its ringo.jar file.) We use maven to develop with Ringo (I know, probably a small minority among this group), but developing enterprise apps requires this level of integration for many companies.

What I would like to see is the ability to include a maven dependency and have it automatically include the dependency's js directory as a ZipResource. Maven actually handles the inclusion of the dependencies jar files and other dependencies automatically.

I was thinking that the package.json file could be checked for all jar files on the classpath and, if found, the lib directory would be added to the repository hierarchy.

-- jim

[Hannes Wallnoefer]

On Aug 23, 3:55 pm, James Cook <jc...@tracermedia.com> wrote:
> While you guys are discussing this, if any progress can be made to
> auto-include the resources from a jar on the classpath would be just great.
> (Just like RingoJS does with its ringo.jar file.) We use maven to develop
> with Ringo (I know, probably a small minority among this group), but
> developing enterprise apps requires this level of integration for many
> companies.
>
> What I would like to see is the ability to include a maven dependency and
> have it automatically include the dependency's js directory as a
> ZipResource. Maven actually handles the inclusion of the dependencies jar
> files and other dependencies automatically.

I'd be happy to implement this, but need a bit more input. How can we
detect a maven dependency? We should look for a js/ directory or a top-
level package.json file within the jar file and automatically add it
to the module search path if it exists?

Hannes

> I was thinking that the package.json file could be checked for all jar files
> on the classpath and, if found, the lib directory would be added to the
> repository hierarchy.
>
> -- jim
>

> > ringojs+u...@googlegroups.com<ringojs%2Bunsu...@googlegroups.com>
> > .

[James Cook]

Hi Hannes,

Looking for a top-level package.json file would allow me to have a maven build that can generate a "package" or a Maven "package" module which would be nice. Most java actions that react to the presence of some kind of flag in a resource file usually key off of a config option in the manifest file, or the presence of a file in META-INF package, but it isn't a hard and fast rule.

Identifying the JAR files to scan for the presence of 'package.json' is a bit harder.

Bill Burke has a good summary of some techniques.

Here is the relevant code for sanning WEB-INF/lib:

List<URL> urls = new ArrayList<URL>();

Set libJars = servletContext.getResourcePaths("/WEB-INF/lib");
for (Object jar : libJars)
{
    try
    {
       urls.add(servletContext.getResource((String) jar));
    }
    catch (MalformedURLException e)
    {
       throw new RuntimeException(e);
    }
}

-- jim

To unsubscribe from this group, send email to ringojs+u...@googlegroups.com.