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.
<br><br>2) I struggled with what to name the ERB constants. Something like what you proposed would be pretty clear. <br><br>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.
<br><br>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.
<br><br>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).
<br><br>Jeff<br><br><div><span class="gmail_quote">On 6/7/06, <b class="gmail_sendername">Deb Lewis</b> <<a href="mailto:djlewis@acm.org">djlewis@acm.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
A few other observations from MV usage:<br><br>(1) generated-file comments should only be inserted into .rhtml files<br><br>-- I'll include a fix for this when new var-subst feature for comment text<br>is committed<br><br>
If necessary to generalize, add MasterView::Configuration setting allowing<br>specification of output file extensions which are erb targets; default value<br>[ '.rhtml' ]<br><br><br>(2) DirectiveHelpers should in some fashion explicitly distinguish:
<br><br> ERB_CONTENT_END = ' %>'<br> ERB_NO_CONTENT_END = ' -%>'<br><br>and we should either drop the current ERB_END or else take a point of view<br>on what the "normal" usage is and then just define additional constant for
<br>the alt. flavor.<br><br>(??review which flavor DirectiveHelpers#erb uses, vs. erb_content??)<br><br><br>(3) suspect we'll eventually want to handle multiple namespaces for<br>directives that MV processes. app might well want to mark its custom
<br>directives with its own namespace; perhaps there will be some std libraries<br>of useful directives (wouldn't that be a good problem to have?!)<br><br>Wasn't clear when I did a quick skim of the current code whether we can
<br>handle that yet, but it would be something to consider/plan for.<br><br><br>(4) need to think about default for when masterview admin controller is<br>exposed in app (always? only in development unless app's config turns it on
<br>for production?)<br><br>And need to understand/document how an app programmer would restrict access<br>to the mv admin controller in their app if they want to do that. (which I<br>think they probably should be doing in a production site) My other top
<br>to-do for migrating some existing sites on rails besides this template stuff<br>is establishing my user authentication/authorization infrastructure, so I<br>hit this issue very soon.<br><br>~ Deb<br><br><br>_______________________________________________
<br>Masterview-devel mailing list<br><a href="mailto:Masterview-devel@rubyforge.org">Masterview-devel@rubyforge.org</a><br><a href="http://rubyforge.org/mailman/listinfo/masterview-devel">http://rubyforge.org/mailman/listinfo/masterview-devel
</a><br></blockquote></div><br>