Camping list - Dec 2011 - Camping Server: automatically serve static files from public/

I''ve been thinking about adding static files support for the Camping
Server, but I''m wondering how it should work.

Alternative 1:

  app.rb
  public
  public/style.css # example

Alternative 2:

  app.rb
  app/public
  app/public/style.css # example

And secondly, how would it work if you have multiple applications?

  camping app.rb app2.rb

And should files be served from where it''s located or where
it''s run?

  app.rb # => contains `require "app2"`
  app/public/foo.html
  app2.rb # => the actual app
  app2/public/foo.html

Should /foo.html be served from app/public or app2/public?

// Magnus Holm

''public'' is a weird word which has special meaning in the
context of web development for legacy reasons. I think we could find a better
word. ''Resources'', ''web'',
''files''?


?
Jenna Fox


On Tuesday, 20 December 2011 at 8:41 AM, Magnus Holm wrote:
> I''ve been thinking about adding static files support for the
Camping
> Server, but I''m wondering how it should work.
>  
> Alternative 1:
>  
> app.rb
> public
> public/style.css # example
>  
> Alternative 2:
>  
> app.rb
> app/public
> app/public/style.css # example
>  
> And secondly, how would it work if you have multiple applications?
>  
> camping app.rb app2.rb
>  
> And should files be served from where it''s located or where
it''s run?
>  
> app.rb # => contains `require "app2"`
> app/public/foo.html
> app2.rb # => the actual app
> app2/public/foo.html
>  
> Should /foo.html be served from app/public or app2/public?
>  
> // Magnus Holm
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org)
> http://rubyforge.org/mailman/listinfo/camping-list
>  
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20111220/7ee7ba22/attachment.html>

On Mon, Dec 19, 2011 at 23:26, Jenna Fox <a at creativepony.com>
wrote:
> ''public'' is a weird word which has special meaning in the
context of web
> development for legacy reasons. I think we could find a better word.
> ''Resources'', ''web'',
''files''?
Phusion Passenger uses ''public'' to run a Rack-application, so
it
certainly makes things easier if we use the same convention.

Mmm that''s true. Lets stick with that.  


?
Jenna Fox


On Tuesday, 20 December 2011 at 9:37 AM, Magnus Holm wrote:
> On Mon, Dec 19, 2011 at 23:26, Jenna Fox <a at creativepony.com
(mailto:a at creativepony.com)> wrote:
> > ''public'' is a weird word which has special meaning
in the context of web
> > development for legacy reasons. I think we could find a better word.
> > ''Resources'', ''web'',
''files''?
> >  
>  
>  
> Phusion Passenger uses ''public'' to run a
Rack-application, so it
> certainly makes things easier if we use the same convention.
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org)
> http://rubyforge.org/mailman/listinfo/camping-list
>  
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20111220/8be13e03/attachment.html>

Plus people familiar with - or switching from ;-) - Rails and other 
frameworks would also feel at home.

On 12/19/2011 3:46 PM, Jenna Fox wrote:
> Mmm that''s true. Lets stick with that.
>
>
> ---
> Jenna Fox
>
> On Tuesday, 20 December 2011 at 9:37 AM, Magnus Holm wrote:
>
>> On Mon, Dec 19, 2011 at 23:26, Jenna Fox <a at creativepony.com 
>> <mailto:a at creativepony.com>> wrote:
>>> ''public'' is a weird word which has special
meaning in the context of web
>>> development for legacy reasons. I think we could find a better
word.
>>> ''Resources'', ''web'',
''files''?
>>
>> Phusion Passenger uses ''public'' to run a
Rack-application, so it
>> certainly makes things easier if we use the same convention.
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org <mailto:Camping-list at
rubyforge.org>
>> http://rubyforge.org/mailman/listinfo/camping-list
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20111219/1126e631/attachment.html>

#1 gets my vote.

Dave

On Mon, Dec 19, 2011 at 6:24 PM, Philippe Monnet <ruby at monnet-usa.com>
wrote:
> Plus people familiar with - or switching from ;-) - Rails and other
> frameworks would also feel at home.
>
>
> On 12/19/2011 3:46 PM, Jenna Fox wrote:
>
> Mmm that''s true. Lets stick with that.
>
>
> ?
> Jenna Fox
>
> On Tuesday, 20 December 2011 at 9:37 AM, Magnus Holm wrote:
>
> On Mon, Dec 19, 2011 at 23:26, Jenna Fox <a at creativepony.com>
wrote:
>
> ''public'' is a weird word which has special meaning in the
context of web
> development for legacy reasons. I think we could find a better word.
> ''Resources'', ''web'',
''files''?
>
>
> Phusion Passenger uses ''public'' to run a
Rack-application, so it
> certainly makes things easier if we use the same convention.
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list


-- 
Dave

I think Alternative 2 makes the most sense. Then you can have multiple apps
that don''t share the public folder. Plus, you put almost everything in
the
app folder anyways so there shouldn''t be a difference now either.
> Alternative 2:
>
>   app.rb
>   app/public
>   app/public/style.css # example
-- 
Twitter: http://twitter.com/bitpuffin/
Blog: http://bitpuffin.tumblr.com/
Github: http://github.com/milkshakepanda/

Den 2011-12-20 00:24:51 skrev Philippe Monnet <ruby at monnet-usa.com>:
> Plus people familiar with - or switching from ;-) - Rails and other
> frameworks would also feel at home.
And switching from Camping to others :) But why would you want to!
-- 
Twitter: http://twitter.com/bitpuffin/
Blog: http://bitpuffin.tumblr.com/
Github: http://github.com/milkshakepanda/

On Tue, Dec 20, 2011 at 11:06:09AM +0100, Isak Andersson
wrote:
> I think Alternative 2 makes the most sense. Then you can have multiple apps
> that don''t share the public folder. Plus, you put almost
everything in the
> app folder anyways so there shouldn''t be a difference now either.
> 
> >Alternative 2:
> >
> >  app.rb
> >  app/public
> >  app/public/style.css # example
I disagree.  In most cases there is only one app (at least for most of
my apps).  So I have an app.rb with stuff under public/.

If there are more apps, there is no way of knowing whether they are
designed to work together and share the same public data, or they are
apps with seperate(d) public data.  Since one has to build the URLs in
the app anyway, why not let the developer decide the layout of public/
to suit a shared or seperated layout?  (One can think of shared
stylesheets, but different sets of icons/PDFs/whathaveyou).

Kind regards,
Paul

-- 
Web: http://paul.luon.net/home/  | Email: paul at luon.net
Jabber/GTalk: paul at luon.net      | GnuPG key ID: 0x50064181

Den 2011-12-20 11:19:40 skrev Paul van Tilburg <paul at luon.net>:
> On Tue, Dec 20, 2011 at 11:06:09AM +0100, Isak Andersson wrote:
>> I think Alternative 2 makes the most sense. Then you can have multiple
>> apps
>> that don''t share the public folder. Plus, you put almost
everything in
>> the
>> app folder anyways so there shouldn''t be a difference now
either.
>>
>> >Alternative 2:
>> >
>> >  app.rb
>> >  app/public
>> >  app/public/style.css # example
>
> I disagree.  In most cases there is only one app (at least for most of
> my apps).  So I have an app.rb with stuff under public/.
>
> If there are more apps, there is no way of knowing whether they are
> designed to work together and share the same public data, or they are
> apps with seperate(d) public data.  Since one has to build the URLs in
> the app anyway, why not let the developer decide the layout of public/
> to suit a shared or seperated layout?  (One can think of shared
> stylesheets, but different sets of icons/PDFs/whathaveyou).
>
> Kind regards,
> Paul
>
Allright, how about making the users set it up themselves?
That way they could put it anywhere they want.

Just do things in the module App module.

Like set :public, File.dirname(__FILE__) +
''/epic/find/the/public'' will
set that to be the
public folder.

Simple enough?

Cheers,

Isak

-- 
Twitter: http://twitter.com/bitpuffin/
Blog: http://bitpuffin.tumblr.com/
Github: http://github.com/milkshakepanda/

I vote number 2 - it keeps apps separated, so you can pop a whole bunch in a
folder and call it a day - Having one big shared public folder is messy and
breaks that model of separation entirely. If people like Isak have existing
arrangements in place, there aught to be some configurable option to specify any
arbitrary folder as the public files.


?
Jenna Fox


On Tuesday, 20 December 2011 at 9:19 PM, Paul van Tilburg wrote:
> On Tue, Dec 20, 2011 at 11:06:09AM +0100, Isak Andersson wrote:
> > I think Alternative 2 makes the most sense. Then you can have multiple
apps
> > that don''t share the public folder. Plus, you put almost
everything in the
> > app folder anyways so there shouldn''t be a difference now
either.
> >  
> > > Alternative 2:
> > >  
> > > app.rb
> > > app/public
> > > app/public/style.css # example
> > >  
> >  
> >  
>  
>  
> I disagree. In most cases there is only one app (at least for most of
> my apps). So I have an app.rb with stuff under public/.
>  
> If there are more apps, there is no way of knowing whether they are
> designed to work together and share the same public data, or they are
> apps with seperate(d) public data. Since one has to build the URLs in
> the app anyway, why not let the developer decide the layout of public/
> to suit a shared or seperated layout? (One can think of shared
> stylesheets, but different sets of icons/PDFs/whathaveyou).
>  
> Kind regards,
> Paul
>  
> --  
> Web: http://paul.luon.net/home/ | Email: paul at luon.net (mailto:paul at
luon.net)
> Jabber/GTalk: paul at luon.net (mailto:paul at luon.net) | GnuPG key ID:
0x50064181
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org)
> http://rubyforge.org/mailman/listinfo/camping-list
>  
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20111220/195722f6/attachment.html>

Not sure what other people are doing but I already have my apps in
separate folders. Each app has:

app/
app/app.rb
app/app/
app/config/
app/public/
app/lib/
app/db/
app/log/

When I launch a new one I just add it to the apache conf and restart.

Dave

On Tue, Dec 20, 2011 at 6:05 AM, Jenna Fox <a at creativepony.com>
wrote:
> I vote number 2 - it keeps apps separated, so you can pop a whole bunch in
a
> folder and call it a day - Having one big shared public folder is messy and
> breaks that model of separation entirely. If people like Isak have existing
> arrangements in place, there aught to be some configurable option to
specify
> any arbitrary folder as the public files.
>
>
> ?
> Jenna Fox
>
> On Tuesday, 20 December 2011 at 9:19 PM, Paul van Tilburg wrote:
>
> On Tue, Dec 20, 2011 at 11:06:09AM +0100, Isak Andersson wrote:
>
> I think Alternative 2 makes the most sense. Then you can have multiple apps
> that don''t share the public folder. Plus, you put almost
everything in the
> app folder anyways so there shouldn''t be a difference now either.
>
> Alternative 2:
>
> app.rb
> app/public
> app/public/style.css # example
>
>
> I disagree. In most cases there is only one app (at least for most of
> my apps). So I have an app.rb with stuff under public/.
>
> If there are more apps, there is no way of knowing whether they are
> designed to work together and share the same public data, or they are
> apps with seperate(d) public data. Since one has to build the URLs in
> the app anyway, why not let the developer decide the layout of public/
> to suit a shared or seperated layout? (One can think of shared
> stylesheets, but different sets of icons/PDFs/whathaveyou).
>
> Kind regards,
> Paul
>
> --
> Web: http://paul.luon.net/home/ | Email: paul at luon.net
> Jabber/GTalk: paul at luon.net | GnuPG key ID: 0x50064181
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list


-- 
Dave

On Tue, Dec 20, 2011 at 11:19, Paul van Tilburg <paul at luon.net>
wrote:
> On Tue, Dec 20, 2011 at 11:06:09AM +0100, Isak Andersson wrote:
>> I think Alternative 2 makes the most sense. Then you can have multiple
apps
>> that don''t share the public folder. Plus, you put almost
everything in the
>> app folder anyways so there shouldn''t be a difference now
either.
>>
>> >Alternative 2:
>> >
>> > ?app.rb
>> > ?app/public
>> > ?app/public/style.css # example
>
> I disagree. ?In most cases there is only one app (at least for most of
> my apps). ?So I have an app.rb with stuff under public/.
>
> If there are more apps, there is no way of knowing whether they are
> designed to work together and share the same public data, or they are
> apps with seperate(d) public data. ?Since one has to build the URLs in
> the app anyway, why not let the developer decide the layout of public/
> to suit a shared or seperated layout? ?(One can think of shared
> stylesheets, but different sets of icons/PDFs/whathaveyou).
>
I think this makes most sense too.

If you have this config.ru:

  require ''app''
  require ''app2''
  map ''/app'' do run App end
  map ''/app2'' do run App2

It''s much easier get a consistent setup in production and development
with a single shared public directory. With separate directories you
now need to configure your web server to:

1. Serve static files at app/public as /app/
2. Serve static files at app2/public as /app/2
3. Serve everything else to Thin/Mongrel/WEBrick

--

Well, running multiple-apps in one process is kinda broken anyway,
because Camping overrides Markaby to prepend the root to all src-,
href- and action-attributes:

  link rel: ''stylesheet'', href: ''/style.css''

If you have mounted that app at /app, then it will actually generate
<link rel="stylesheet" href="/app/style.css">. So
you''re pretty much
stuck within your app anyway?