A few other observations from MV usage:
(1) generated-file comments should only be inserted into .rhtml files
-- I''ll include a fix for this when new var-subst feature for comment
text
is committed
If necessary to generalize, add MasterView::Configuration setting allowing
specification of output file extensions which are erb targets; default value
[ ''.rhtml'' ]
(2) DirectiveHelpers should in some fashion explicitly distinguish:
ERB_CONTENT_END = '' %>''
ERB_NO_CONTENT_END = '' -%>''
and we should either drop the current ERB_END or else take a point of view
on what the "normal" usage is and then just define additional constant
for
the alt. flavor.
(??review which flavor DirectiveHelpers#erb uses, vs. erb_content??)
(3) suspect we''ll eventually want to handle multiple namespaces for
directives that MV processes. app might well want to mark its custom
directives with its own namespace; perhaps there will be some std libraries
of useful directives (wouldn''t that be a good problem to have?!)
Wasn''t clear when I did a quick skim of the current code whether we can
handle that yet, but it would be something to consider/plan for.
(4) need to think about default for when masterview admin controller is
exposed in app (always? only in development unless app''s config turns
it on
for production?)
And need to understand/document how an app programmer would restrict access
to the mv admin controller in their app if they want to do that. (which I
think they probably should be doing in a production site) My other top
to-do for migrating some existing sites on rails besides this template stuff
is establishing my user authentication/authorization infrastructure, so I
hit this issue very soon.
~ Deb
1) agreed, generated comment is only for erb files as it currently is. (Are we ok not putting anything in other files??, should we think about doing that? For now let''s keep it simple, but someday we may want to have different comment types for different types of files, so users know this is generated. 2) I struggled with what to name the ERB constants. Something like what you proposed would be pretty clear. 3) We can handle directives created in other module namespaces but they still all get mapped down to one prefix currently. You can control the what the attribute name is is used independent of directive class name so it is pretty flexible (defaults to lowercase directive class name). However I see your point in that it would be nice to support multiple namespaces, that would be a nicer thing to do. We would just map a prefix to a module namespace and everything works pretty nicely. I wish I had thought of that earlier, but probably won''t be too hard to retrofit. 4) I thought about doing a variety of schemes for user authentication, even something as simple as having a set user password and only doing it in development, etc. However I went with the simplest approach at first figuring there are many ways to skin this. I had used the engines version of RBAC for a project and that worked out pretty nice because it was pretty unintrusive. Bolt on authentication is nice. However I didn''t want to put any big dependencies on things since the current plugin mechanism doesn''t have a nice way to do dependencies (that I am aware of) so users have to manually install prerequisites or one has to bundle them in (which is generally not the best way). I think eventually plugins will move toward something more like gems, but the gems system needs to be made easier to use without root access (for shared servers). Jeff On 6/7/06, Deb Lewis <djlewis at acm.org> wrote:> > A few other observations from MV usage: > > (1) generated-file comments should only be inserted into .rhtml files > > -- I''ll include a fix for this when new var-subst feature for comment text > is committed > > If necessary to generalize, add MasterView::Configuration setting allowing > specification of output file extensions which are erb targets; default > value > [ ''.rhtml'' ] > > > (2) DirectiveHelpers should in some fashion explicitly distinguish: > > ERB_CONTENT_END = '' %>'' > ERB_NO_CONTENT_END = '' -%>'' > > and we should either drop the current ERB_END or else take a point of view > on what the "normal" usage is and then just define additional constant for > the alt. flavor. > > (??review which flavor DirectiveHelpers#erb uses, vs. erb_content??) > > > (3) suspect we''ll eventually want to handle multiple namespaces for > directives that MV processes. app might well want to mark its custom > directives with its own namespace; perhaps there will be some std > libraries > of useful directives (wouldn''t that be a good problem to have?!) > > Wasn''t clear when I did a quick skim of the current code whether we can > handle that yet, but it would be something to consider/plan for. > > > (4) need to think about default for when masterview admin controller is > exposed in app (always? only in development unless app''s config turns it > on > for production?) > > And need to understand/document how an app programmer would restrict > access > to the mv admin controller in their app if they want to do that. (which I > think they probably should be doing in a production site) My other top > to-do for migrating some existing sites on rails besides this template > stuff > is establishing my user authentication/authorization infrastructure, so I > hit this issue very soon. > > ~ Deb > > > _______________________________________________ > Masterview-devel mailing list > Masterview-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/masterview-devel >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060607/2aacd4b8/attachment.htm
response interspersed below. ~ Deb _____ From: masterview-devel-bounces at rubyforge.org [mailto:masterview-devel-bounces at rubyforge.org] On Behalf Of Jeff Barczewski Sent: Wednesday, June 07, 2006 12:28 PM To: masterview-devel at rubyforge.org Subject: Re: [Masterview-devel] A few observations from MV usage 1) agreed, generated comment is only for erb files as it currently is. (Are we ok not putting anything in other files??, should we think about doing that? For now let''s keep it simple, but someday we may want to have different comment types for different types of files, so users know this is generated. I thought about allowing diff comments for diff types but files, but then decided that''s ridiculous overkill. We can invent that in the future if needed. ... 4) I thought about doing a variety of schemes for user authentication, even something as simple as having a set user password and only doing it in development, etc. However I went with the simplest approach at first figuring there are many ways to skin this. I had used the engines version of RBAC for a project and that worked out pretty nice because it was pretty unintrusive. Bolt on authentication is nice. However I didn''t want to put any big dependencies on things since the current plugin mechanism doesn''t have a nice way to do dependencies (that I am aware of) so users have to manually install prerequisites or one has to bundle them in (which is generally not the best way). I think eventually plugins will move toward something more like gems, but the gems system needs to be made easier to use without root access (for shared servers). I don''t have an answer for this yet, just want us to be thinking about it. And no, we certainly shouldn''t have any big dependencies in the core MV plugin. Maybe someday there''s MV add-ons if it made sense to standardize hookup with something widely used, but it doesn''t seem that area of the rails world has settled into anything standard yet. There are several diff auth schemes out there, including really simple roll-your-own, and no precedent in place for standardized protocol that we could leverage to auto-detect whether/how to filter access. FWIW I''ll likely to end up doing something with Bruce Perens'' ModelSecurity for my own app infrastructure, after incomplete initial research into available options. Or possibly ActiveRBAC - not sure. I want to be able to start with something relatively simple, but with notions of roles and permissions in the foundation so I can scale in the future to more sophisticated schemes as needed. http://perens.com/FreeSoftware/ModelSecurity/Tutorial.html ~ Deb -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060607/bf21741e/attachment.htm
Mine too. On 6/7/06, Deb Lewis <djlewis at acm.org> wrote:> > response interspersed below. > > ~ Deb > > ------------------------------ > *From:* masterview-devel-bounces at rubyforge.org [mailto: > masterview-devel-bounces at rubyforge.org] *On Behalf Of *Jeff Barczewski > *Sent:* Wednesday, June 07, 2006 12:28 PM > *To:* masterview-devel at rubyforge.org > *Subject:* Re: [Masterview-devel] A few observations from MV usage > > 1) agreed, generated comment is only for erb files as it currently is. > (Are we ok not putting anything in other files??, should we think about > doing that? For now let''s keep it simple, but someday we may want to have > different comment types for different types of files, so users know this is > generated. > > I thought about allowing diff comments for diff types but files, but then > decided that''s ridiculous overkill. We can invent that in the future if > needed. >Absolutely. Let''s keep it simple, it will get complicated enough on its own. We can add when needed. ...> > 4) I thought about doing a variety of schemes for user authentication, > even something as simple as having a set user password and only doing it in > development, etc. However I went with the simplest approach at first > figuring there are many ways to skin this. > > I had used the engines version of RBAC for a project and that worked out > pretty nice because it was pretty unintrusive. Bolt on authentication is > nice. However I didn''t want to put any big dependencies on things since the > current plugin mechanism doesn''t have a nice way to do dependencies (that I > am aware of) so users have to manually install prerequisites or one has to > bundle them in (which is generally not the best way). I think eventually > plugins will move toward something more like gems, but the gems system needs > to be made easier to use without root access (for shared servers). > > I don''t have an answer for this yet, just want us to be thinking about > it. And no, we certainly shouldn''t have any big dependencies in the core MV > plugin. > > Maybe someday there''s MV add-ons if it made sense to standardize hookup > with something widely used, but it doesn''t seem that area of the rails world > has settled into anything standard yet. There are several diff auth > schemes out there, including really simple roll-your-own, and no precedent > in place for standardized protocol that we could leverage to auto-detect > whether/how to filter access. > > FWIW I''ll likely to end up doing something with Bruce Perens'' > ModelSecurity for my own app infrastructure, after incomplete initial > research into available options. Or possibly ActiveRBAC - not sure. I want > to be able to start with something relatively simple, but with notions of > roles and permissions in the foundation so I can scale in the future to more > sophisticated schemes as needed. > > http://perens.com/FreeSoftware/ModelSecurity/Tutorial.html > >Thanks, I''ll check Bruce''s stuff out. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060607/8c8fcdb9/attachment.htm