This isn''t affecting my app, but I''d like to know the reason
why I''m
seeing this. In my layout, the following code
<%= image_tag "front.jpg", :size =>"760x175" %>
generates
<img alt="Front" height="175"
src="/images/front.jpg?1122106054"
width="760" />
Where is the parameter in the image src URL coming from, and why is it
there? I looked at the image tag source, and didn''t see anything
obvious. I don''t think it''s an articfact of my browser, but
I''m really
not sure. I also see a similar weird parameter on my generated style
links.
Thanks
Jim
--
Posted via http://www.ruby-forum.com/.
The answer is in the following write up http://hypsometry.com/blog/on-browser-caching-asset-timestamping-and-rails I don''t like it. Though the URL''s are internal to the page source, they''re ugly and as pointed out, this appears to break caching as per the W3C spec. It seems I should be able to get rid of it by setting ENV["RAILS_ASSET_ID"] to a zero length string . . . Jim Frohnhofer wrote:> This isn''t affecting my app, but I''d like to know the reason why I''m > seeing this. In my layout, the following code > > <%= image_tag "front.jpg", :size =>"760x175" %> > > generates > > <img alt="Front" height="175" src="/images/front.jpg?1122106054" > width="760" /> > > Where is the parameter in the image src URL coming from, and why is it > there? I looked at the image tag source, and didn''t see anything > obvious. I don''t think it''s an articfact of my browser, but I''m really > not sure. I also see a similar weird parameter on my generated style > links. > > Thanks > > Jim-- Posted via http://www.ruby-forum.com/.
And my last complaint is that this makes the api documentation wrong. Jim Frohnhofer wrote:> The answer is in the following write up > > http://hypsometry.com/blog/on-browser-caching-asset-timestamping-and-rails> Jim Frohnhofer wrote: >> This isn''t affecting my app, but I''d like to know the reason why I''m >> seeing this. In my layout, the following code >> >> <%= image_tag "front.jpg", :size =>"760x175" %> >> >> generates >> >> <img alt="Front" height="175" src="/images/front.jpg?1122106054" >> width="760" /> >>-- Posted via http://www.ruby-forum.com/.
I already have AWDWR and have done a number of tutorials , so it''s okay to refer me to those however I''d prefer, if there is a semi-simple answer to this to perhaps offer one up. I want to build a site that will work around "role based" authentication and I''m thinking about it in relation to my directory structure. so the roles might be: company group user-gold user-silver would I build a directory structure like: company/index company/do_something company/do_something_else group/index group/do_something group/do_something_else .. usergold/index usergold/do_something .................... and on if this makes sense , do I then make controllers for each page ? i.e: generate controller company index generate controller company do_something_else generate controller usergold do_something Or am I totally missing something here ? Hope I made the question clear enough. Appreciate any explanation TIA Stuart -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060712/1685532a/attachment.html
If you haven''t already, watch the blog demo video: http://media.rubyonrails.org/video/rails_take2_with_sound.mov Is a great tutorial that may help you understand controllers/directories. Your controller names will show up in your URLs, so you should pick controller names that make sense like: login (holds all your login login), users (holds your user logic), groups (etc etc). -- Posted via http://www.ruby-forum.com/.
On 12/07/06, David C. <dave@pezians.com> wrote:> Your controller names will show up in your URLs, so you should pick > controller names that make sense like: login (holds all your login > login), users (holds your user logic), groups (etc etc). >No, your controller names will show up in your URLs *by default*. This can, of course, be changed in routes.rb. As regards structuring your app: I don''t think you need a seperate controller for each level of access. You might want to seperate out (say) an administrative/corporate backend from a user-facing front end, though. To give you an example based on what you''ve given us: why do you need a user-gold controller and a user-silver controller? Why not just have a user controller, store the user''s access level in a cookie/session, and then display content conditionally dependent on their status? Using a controller for each access level will lead to lots of repetition. In this case, that''s a bad thing.
On 7/12/06, Tom Armitage <tom.armitage@gmail.com> wrote:> > > To give you an example based on what you''ve given us: why do you need > a user-gold controller and a user-silver controller? Why not just have > a user controller, store the user''s access level in a cookie/session, > and then display content conditionally dependent on their status? > > > Probably don''t need seperate ones. I''ll narrow it down for the moment soperhaps my confusion can be cleared up: so usergold after logging in goes to usergold/index (from there there are links and perhaps some of their account information) the links might be usergold/searcharticles usergold/postarticles usergold/checkforum usergold/upgrade I guess, the way it works is all the code is in the usergold controller and then each function has it''s methods and within those functions information about the correct view to pull up ? Stuart -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060712/d565d9d4/attachment.html
> so usergold after logging in goes to> usergold/index (from there there are links and perhaps some of their > account information) > the links might be > usergold/searcharticles > usergold/postarticles > usergold/checkforum > usergold/upgrade > This is really not a cool idea IMO. What Tom suggested is the way to go. Create your controllers to handle the content and protect using filters. Your controllers should look something like: user/ articles/search/ articles/post/ forums/1/ memberships/upgrade/ Steve
> Probably don''t need seperate ones. I''ll narrow it down for the moment so > perhaps my confusion can be cleared up: > so usergold after logging in goes to > usergold/index (from there there are links and perhaps some of their account > information) > the links might be > usergold/searcharticles > usergold/postarticles > usergold/checkforum > usergold/upgrade > > I guess, the way it works is all the code is in the usergold controller and > then each function has it''s methods and within those functions information > about the correct view to pull up ?Maybe. Let''s get the terminology right, though, for clarity: if there''s some conditional data, you might want to put some conditional statements into each action in the controller so that only the necessary data is passed to the view. You could then put conditional statements in the view to show extra stuff for certain classes of users. Alternatively, if there are some pages that only a "gold" user might see, then it might be worth making seperate views for those, and then putting the call to render that view in a conditional statement on the controller. Does that make sense?
On 7/12/06, Tom Armitage <tom.armitage@gmail.com> wrote:> > I guess, the way it works is all the code is in the usergold controller > and > > then each function has it''s methods and within those functions > information > > about the correct view to pull up ? > > Maybe. Let''s get the terminology right, though, for clarity: > > if there''s some conditional data, you might want to put some > conditional statements into each action in the controller so that only > the necessary data is passed to the view. You could then put > conditional statements in the view to show extra stuff for certain > classes of users.Okay I understand that and have done that similarly in PHP (not to dredge up that beast :)) As well, blocked entire pages based on the access level of the user. Alternatively, if there are some pages that only a "gold" user might> see, then it might be worth making seperate views for those, and then > putting the call to render that view in a conditional statement on the > controller. Does that make sense?Yes, it makes sense. Unfortunately I am still stuck back at part of my original question, but will ask it again in a revised form in light of these clarificaitons - Should I just forget about the idea of "directories" when designing in ROR ? Stuart _______________________________________________> Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060712/12074852/attachment.html
Create your controllers based on the actions that users will be
doing. Then, separately, construct your urls using routes to have
the "directories" look however you want them to.
e.g.: map.connect '':year/:month/:day'', :controller =>
''blog'', :action => ''by_date''
For a simple app, you should easily be able to have a number of
controllers, each with a number of actions, without needing any more
hierarchy in your controller directory. What you expose to users is
entirely independent.
http://manuals.rubyonrails.com/read/chapter/65
New question: what happened to the API docs for
ActionController::Routing?
http://api.rubyonrails.com/
- dan
--
Dan Kohn <mailto:dan@dankohn.com>
<http://www.dankohn.com/> <tel:+1-415-233-1000>
On Jul 12, 2006, at 10:46 AM, Dark Ambient wrote:
>
>
> On 7/12/06, Tom Armitage <tom.armitage@gmail.com> wrote:
> > I guess, the way it works is all the code is in the usergold
> controller and
> > then each function has it''s methods and within those
functions
> information
> > about the correct view to pull up ?
>
> Maybe. Let''s get the terminology right, though, for clarity:
>
> if there''s some conditional data, you might want to put some
> conditional statements into each action in the controller so that only
> the necessary data is passed to the view. You could then put
> conditional statements in the view to show extra stuff for certain
> classes of users.
>
> Okay I understand that and have done that similarly in PHP (not to
> dredge up that beast :))
> As well, blocked entire pages based on the access level of the user.
>
> Alternatively, if there are some pages that only a "gold" user
might
> see, then it might be worth making seperate views for those, and then
> putting the call to render that view in a conditional statement on the
> controller. Does that make sense?
>
> Yes, it makes sense. Unfortunately I am still stuck back at part
> of my original question, but will ask it again in a revised form in
> light of these clarificaitons -
> Should I just forget about the idea of "directories" when
designing
> in ROR ?
>
> Stuart
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060712/cded3265/attachment-0001.html
Thanks Dan, just got done reading about routing and also the section in AWDWR. I see the point though in coming back after the controllers are set up. Stuart On 7/12/06, Dan Kohn <dan@dankohn.com> wrote:> > Create your controllers based on the actions that users will be doing. > Then, separately, construct your urls using routes to have the "directories" > look however you want them to. > e.g.: map.connect '':year/:month/:day'', :controller => ''blog'', :action => > ''by_date'' > > For a simple app, you should easily be able to have a number of > controllers, each with a number of actions, without needing any more > hierarchy in your controller directory. What you expose to users is > entirely independent. > > http://manuals.rubyonrails.com/read/chapter/65 > > New question: what happened to the API docs for ActionController::Routing? > http://api.rubyonrails.com/ > > - dan > -- > Dan Kohn <mailto:dan@dankohn.com <dan@dankohn.com>> > <http://www.dankohn.com/> <tel:+1-415-233-1000> > > > > On Jul 12, 2006, at 10:46 AM, Dark Ambient wrote: > > > > On 7/12/06, Tom Armitage <tom.armitage@gmail.com> wrote: > > > > I guess, the way it works is all the code is in the usergold > > controller and > > > then each function has it''s methods and within those functions > > information > > > about the correct view to pull up ? > > > > Maybe. Let''s get the terminology right, though, for clarity: > > > > if there''s some conditional data, you might want to put some > > conditional statements into each action in the controller so that only > > the necessary data is passed to the view. You could then put > > conditional statements in the view to show extra stuff for certain > > classes of users. > > > Okay I understand that and have done that similarly in PHP (not to dredge > up that beast :)) > As well, blocked entire pages based on the access level of the user. > > Alternatively, if there are some pages that only a "gold" user might > > see, then it might be worth making seperate views for those, and then > > putting the call to render that view in a conditional statement on the > > controller. Does that make sense? > > > Yes, it makes sense. Unfortunately I am still stuck back at part of my > original question, but will ask it again in a revised form in light of these > clarificaitons - > Should I just forget about the idea of "directories" when designing in ROR > ? > > Stuart > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060712/b6c380c7/attachment-0001.html