One of the projects that I''m working on creates and twiddles with a lot of directories. In version 1, I did this all in the controllers, but I''m beginning to think that the whole design would be cleaner in v2 if I made the filesystem a model. My plan for going about this would be to generate a model (Filesystem), but create no migration for it, and then override all of the methods I''d want to use in app/models/filesystem.rb All of the directories are directly related to another model, so it''d just be passing :id into the model functions. (unlock_dir, lock_dir, create, destroy, etc) Does this seem like a stupid solution? Is there a much better way that I''m missing? Thanks -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 4/24/07, Jonathan Dobbie <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > One of the projects that I''m working on creates and twiddles with a lot > of directories. In version 1, I did this all in the controllers, but > I''m beginning to think that the whole design would be cleaner in v2 if I > made the filesystem a model.> My plan for going about this would be to generate a model (Filesystem), > but create no migration for it, and then override all of the methods I''d > want to use in app/models/filesystem.rb> All of the directories are directly related to another model, so it''d > just be passing :id into the model functions. (unlock_dir, lock_dir, > create, destroy, etc)> Does this seem like a stupid solution? Is there a much better way that > I''m missing?Well I think you might be abusing the abstraction. It might work, maybe somebody has already implemented something similar successfully. I think you were closer to a good representation the first time: do the work in the controllers. Or better yet, farm the effort out to controller helpers or even something global like a plugin. Ruby''s file processing and directory crawling methods are very powerful, hiding them under a lot of inappropriate abstraction layers, reimplementing them as finders etc. just seems like the wrong thing to do. I think you were right the first time. However you will miss out on Model Validations, which is probably why you thought of file system modeling? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 4/25/07, Richard Conroy <richard.conroy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > On 4/24/07, Jonathan Dobbie <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote: > > > > One of the projects that I''m working on creates and twiddles with a lot > > of directories. In version 1, I did this all in the controllers, but > > I''m beginning to think that the whole design would be cleaner in v2 if I > > made the filesystem a model. > > > My plan for going about this would be to generate a model (Filesystem), > > but create no migration for it, and then override all of the methods I''d > > want to use in app/models/filesystem.rb > > > All of the directories are directly related to another model, so it''d > > just be passing :id into the model functions. (unlock_dir, lock_dir, > > create, destroy, etc) > > > Does this seem like a stupid solution? Is there a much better way that > > I''m missing? > > Well I think you might be abusing the abstraction. It might work, maybe > somebody has already implemented something similar successfully. > > I think you were closer to a good representation the first time: do the > work in the controllers. Or better yet, farm the effort out to controller > helpers or even something global like a plugin. > > Ruby''s file processing and directory crawling methods are very powerful, > hiding them under a lot of inappropriate abstraction layers, reimplementing > them as finders etc. just seems like the wrong thing to do. I think you > were right the first time. >I''ve written a lot of ''heavy'' controllers and think the approach has some advantages. It''s usually less work than coming up with a domain layer with a clean/elegant interface, IMO, but it usually ends up smelling a bit strange. Imagine what happens if Jonathan wants to do a GUI or CLI -based port of his app; new presentation layers would require new controllers, and he''d have to rewrite, or at least copy+paste, his file system code for each environment. Granted, this doesn''t apply to most projects, but i still believe there''s a maintainability issue. The model directory is where all your other domain logic is kept, and I don''t see any fundamental difference between AR backed and non-db models, so why keep them apart..? If it''s app specific code, it really doesn''t belong in a library. You''d also get to unit test your classes easily, which is a big plus in my book. Regards, Isak> However you will miss out on Model Validations, which is probably why > you thought of file system modeling? > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> Imagine what happens if Jonathan wants to do a GUI or CLI -based port > of his app; new presentation layers would require new controllers, and > he''d have to rewrite, or at least copy+paste, his file system code for > each environment. > Granted, this doesn''t apply to most projects, but i still believe > there''s a maintainability issue.About half of the project is a daemon with no view, which is what led me down this path. In version 1, I copied and pasted the code between the controllers and the daemon, and I really want to avoid that in version 2. Is it possible to have Models that aren''t decended from ActiveRecord::Base? Conceptually, I''m definitely using the filesystem as a model, and I''d really like to have a unified interface between the web app and the daemon. There is also a very small number of actions that I''ll need to do, and these are heavily shared between the daemon and web app. I guess I could use a plugin, but that seems even more hackish (from a design standpoint). I''m still not really sure what the ''rails way'' is in these situations. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> Is it possible to have Models that aren''t decended from ActiveRecord::Base?Absolutely. In the project I''m currently working on, one of the models is a small number of static objects, which are initialised from a YAML template which is hardcoded within the model file itself. There is another model which implements a concept of "groups": the database has no separate table for groups, but rather group memberships are attributes of other model objects. So in this case this is a sort of ''virtual'' model. For example, if you ask it for a list of all groups, then what it actually does is a "select distinct(grp) from [other model table]". Of course, if your model isn''t descended from ActiveRecord::Base, then the API it exposes to the controllers may well be very different to ActiveRecord, but since these are also your own controllers this isn''t a problem. The other way to have filesystem-backed models is to use ActiveRecord with sqlite, but I don''t think that''s what you''re asking for :-) Anyway, I''d say you should feel free to build your own non-AR model. You then put logic as to what to *do* with the model in the controllers. This is assuming that your model is somehow "adding value" over basic filesystem operations. If the API it provides is just "list files", "open file", "delete file" then maybe the controller should use the native IO methods for those. But even then, a thin model layer could perform basic filename validation and restrict access to certain directories. Just my 2c... Brian. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---