From ed.howland at gmail.com Wed Jul 5 12:27:15 2006 From: ed.howland at gmail.com (Ed Howland) Date: Wed, 5 Jul 2006 11:27:15 -0500 Subject: [Masterview-users] Urgent Help! - User directives no longer functioning in 0.2.2 Message-ID: <3df642dd0607050927s52b0d219t252c70362f2e379b@mail.gmail.com> After upgrading to 0.2.2, my directives in vendor/plugins/masterview/directives no longer function. Scanned all the documentation and could not find _any_ information on user created directives. Reading the code itself, there seems to be 2 commented out sections. One refers to app/masterview/directives and the other refers to config/masterview/directives. Seems to be a lot of TODO commentary. Why were user directives disabled in this release and no notification given? Is there a work around? I desperately need to get my code working again. Thanks Ed -- Ed Howland http://greenprogrammer.blogspot.com From jeff.barczewski at gmail.com Wed Jul 5 13:47:04 2006 From: jeff.barczewski at gmail.com (Jeff Barczewski) Date: Wed, 5 Jul 2006 12:47:04 -0500 Subject: [Masterview-users] Urgent Help! - User directives no longer functioning in 0.2.2 In-Reply-To: <3df642dd0607050927s52b0d219t252c70362f2e379b@mail.gmail.com> References: <3df642dd0607050927s52b0d219t252c70362f2e379b@mail.gmail.com> Message-ID: <19cda190607051047x360b8cbdpf7bdd424262e8394@mail.gmail.com> We didn't intentionally remove user level directives from the release. We consider it a benefit to allow user created directives. I would guess that since the newer version uses new configuration of how those user directive paths are specified that this is what broke things for you. Check your config/masterview/settings.rb that you have specified config.directive_paths << /path/to/my/directives to include your directive directories. I will run some tests to verify whether there are any issues with this. Also note that you can also manually 'require' any files that you want if you do it after you require 'masterview'. This will allow you to manually load any directives anywhere in your path including inside of gems. They simply have to be done after masterview though so that MasterView will become aware of them as they load. Jeff On 7/5/06, Ed Howland wrote: > > After upgrading to 0.2.2, my directives in > vendor/plugins/masterview/directives no longer function. Scanned all > the documentation and could not find _any_ information on user created > directives. > > Reading the code itself, there seems to be 2 commented out sections. > One refers to app/masterview/directives and the other refers to > config/masterview/directives. Seems to be a lot of TODO commentary. > > Why were user directives disabled in this release and no notification > given? Is there a work around? I desperately need to get my code > working again. > > Thanks > > Ed > > -- > Ed Howland > http://greenprogrammer.blogspot.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-users/attachments/20060705/fec4b3eb/attachment.html From ed.howland at gmail.com Wed Jul 5 14:18:18 2006 From: ed.howland at gmail.com (Ed Howland) Date: Wed, 5 Jul 2006 13:18:18 -0500 Subject: [Masterview-users] Urgent Help! - User directives no longer functioning in 0.2.2 In-Reply-To: <19cda190607051047x360b8cbdpf7bdd424262e8394@mail.gmail.com> References: <3df642dd0607050927s52b0d219t252c70362f2e379b@mail.gmail.com> <19cda190607051047x360b8cbdpf7bdd424262e8394@mail.gmail.com> Message-ID: <3df642dd0607051118q2e57ac15y4fe6e6c9e03efeb3@mail.gmail.com> Thanks Jeff. I got confused by the masterview_plugin generator which when I ran it created 'vendor/plugins/masterview/directives' which was where I installed them previously. Since that option was commented out, I assumed it still picked up any there and that you could add additional ones in the settings. I suggest that you make a note of this in the announcement, since others may run into this as well. Also, I never explicitly require 'masterview' anywhere. Are you suggesting this in one of the normal Rails configuration files? Or in vendor/plugins/masterview/init.rb? Thanks Ed On 7/5/06, Jeff Barczewski wrote: > We didn't intentionally remove user level directives from the release. We > consider it a benefit to allow user created directives. > > I would guess that since the newer version uses new configuration of how > those user directive paths are specified that this is what broke things for > you. > > Check your config/masterview/settings.rb that you have specified > config.directive_paths << /path/to/my/directives > > to include your directive directories. > > I will run some tests to verify whether there are any issues with this. > > Also note that you can also manually 'require' any files that you want if > you do it after you require 'masterview'. This will allow you to manually > load any directives anywhere in your path including inside of gems. They > simply have to be done after masterview though so that MasterView will > become aware of them as they load. > > Jeff > > > On 7/5/06, Ed Howland wrote: > > After upgrading to 0.2.2, my directives in > > vendor/plugins/masterview/directives no longer function. > Scanned all > > the documentation and could not find _any_ information on user created > > directives. > > > > Reading the code itself, there seems to be 2 commented out sections. > > One refers to app/masterview/directives and the other refers to > > config/masterview/directives. Seems to be a lot of TODO commentary. > > > > Why were user directives disabled in this release and no notification > > given? Is there a work around? I desperately need to get my code > > working again. > > > > Thanks > > > > Ed > > > > -- > > Ed Howland > > http://greenprogrammer.blogspot.com > > > > -- Ed Howland http://greenprogrammer.blogspot.com From jeff.barczewski at gmail.com Wed Jul 5 14:33:44 2006 From: jeff.barczewski at gmail.com (Jeff Barczewski) Date: Wed, 5 Jul 2006 13:33:44 -0500 Subject: [Masterview-users] Urgent Help! - User directives no longer functioning in 0.2.2 In-Reply-To: <3df642dd0607051118q2e57ac15y4fe6e6c9e03efeb3@mail.gmail.com> References: <3df642dd0607050927s52b0d219t252c70362f2e379b@mail.gmail.com> <19cda190607051047x360b8cbdpf7bdd424262e8394@mail.gmail.com> <3df642dd0607051118q2e57ac15y4fe6e6c9e03efeb3@mail.gmail.com> Message-ID: <19cda190607051133h2f45c499uc63b07ed7dc346c4@mail.gmail.com> Yes, we need to make that clearer. Deb has been working on the user directive side of things so I'll see if she has any good ideas on that front. So everything appears to be working if you add in any directive directories to the config.directive_paths, but we'll make sure that either we communicate that better. As for doing manual require's you shouldn't have to, but I wanted to provide full flexibility to do this if necessary. You could do this in init.rbhowever ideally we would do it with the settings.rb, so not sure if we can simply put require's in there or not? Deb? (The main reason this might be needed is if you want to manually include a single file or to include a gem of directives). On 7/5/06, Ed Howland wrote: > > Thanks Jeff. I got confused by the masterview_plugin generator which > when I ran it created 'vendor/plugins/masterview/directives' which was > where I installed them previously. Since that option was commented > out, I assumed it still picked up any there and that you could add > additional ones in the settings. > > I suggest that you make a note of this in the announcement, since > others may run into this as well. > > Also, I never explicitly require 'masterview' anywhere. Are you > suggesting this in one of the normal Rails configuration files? Or in > vendor/plugins/masterview/init.rb? > > Thanks > Ed > > > > On 7/5/06, Jeff Barczewski wrote: > > We didn't intentionally remove user level directives from the release. > We > > consider it a benefit to allow user created directives. > > > > I would guess that since the newer version uses new configuration of how > > those user directive paths are specified that this is what broke things > for > > you. > > > > Check your config/masterview/settings.rb that you have specified > > config.directive_paths << /path/to/my/directives > > > > to include your directive directories. > > > > I will run some tests to verify whether there are any issues with this. > > > > Also note that you can also manually 'require' any files that you want > if > > you do it after you require 'masterview'. This will allow you to > manually > > load any directives anywhere in your path including inside of gems. They > > simply have to be done after masterview though so that MasterView will > > become aware of them as they load. > > > > Jeff > > > > > > On 7/5/06, Ed Howland wrote: > > > After upgrading to 0.2.2, my directives in > > > vendor/plugins/masterview/directives no longer function. > > Scanned all > > > the documentation and could not find _any_ information on user created > > > directives. > > > > > > Reading the code itself, there seems to be 2 commented out sections. > > > One refers to app/masterview/directives and the other refers to > > > config/masterview/directives. Seems to be a lot of TODO commentary. > > > > > > Why were user directives disabled in this release and no notification > > > given? Is there a work around? I desperately need to get my code > > > working again. > > > > > > Thanks > > > > > > Ed > > > > > > -- > > > Ed Howland > > > http://greenprogrammer.blogspot.com > > > > > > > > > > -- > Ed Howland > http://greenprogrammer.blogspot.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-users/attachments/20060705/0f8c3b8b/attachment-0001.html From jeff.barczewski at gmail.com Wed Jul 5 20:01:18 2006 From: jeff.barczewski at gmail.com (Jeff Barczewski) Date: Wed, 5 Jul 2006 19:01:18 -0500 Subject: [Masterview-users] [ANN] MasterView rails-optimized (x)html friendly template engine - Release 0.2.3 Message-ID: <19cda190607051701p785cb17ao2e64057fb77b44a@mail.gmail.com> MasterView is a rails-optimized (x)html friendly template engine plugin that provides another option to the existing rails view templates (rhtml and rxml). The main idea is to provide a template engine that would provide all the power of layouts, partials, and rails helpers but still be editable/styleable in a WYSIWYG editor. It was also a major goal that the syntax of these attribute directives be very similar to rails helpers so that one could intuitively start using MasterView with little learning curve other than knowing rails. MasterView was inspired by Amrita, Kwartz, Tapestry, Zope/PHP TAL, Liquid, and Web Objects but designed with a fresh approach and specifically targetted for rails users. Release Notes Release 0.2.3 Changed default development settings for enable_admin_pages and enable_view_rhtml = true (false in production) to make it easy for new users to get up and running. Added check_box, radio_button, select, collection_select directives. Refactor attr_value parsing to be more robust taking into account nested objects. Internal rework of directive handling to support alternate namespaces for directives. Std app directives dir at rails app/masterview/directives will be automatically added to MasterView load path if exists. Visit http://masterview.org/ for screenshots, illustrations, videos, and documentation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-users/attachments/20060705/89ca8c3f/attachment.html From djlewis at acm.org Thu Jul 6 01:05:41 2006 From: djlewis at acm.org (Deb Lewis) Date: Wed, 5 Jul 2006 22:05:41 -0700 Subject: [Masterview-users] Urgent Help! - User directives no longer functioning in 0.2.2 In-Reply-To: <3df642dd0607051118q2e57ac15y4fe6e6c9e03efeb3@mail.gmail.com> Message-ID: <20060706050545.GJOH985.fed1rmmtao12.cox.net@DLI92cx797990> Ed wrote in response to Jeff's remarks: >> Also, I never explicitly require 'masterview' anywhere. >> Are you suggesting this in one of the normal Rails configuration >> files? Or in vendor/plugins/masterview/init.rb? No, you shouldn't have to write 'require masterview' in a normal rails app. That all gets handled by the standard rails framework loading mechanism. (we actually do that in the masterview plugin's init.rb file, but that's a std file that user's don't generally know or care about, and in contrast to early versions of MV should generally *not* be modified) There are some cases when you might need to explicit load masterview via a require, but they're generally outside the context of a rails app or because you're doing something tricky down in plugin loading and rails startup. Not likely for most users. So - if you do nothing at all, you'll get stock MasterView configuration once you've installed the plugin in your rails app. If you choose to provide config/masterview settings files, you can customize your config (but you don't have to). And as of 0.2.3, if you place custom directive implementations in app/masterview/directives, they'll be automatically loaded along with the builtin rails directives. ~ Deb On 7/5/06, Jeff Barczewski wrote: > We didn't intentionally remove user level directives from the release. > We consider it a benefit to allow user created directives. > > I would guess that since the newer version uses new configuration of > how those user directive paths are specified that this is what broke > things for you. > > Check your config/masterview/settings.rb that you have specified > config.directive_paths << /path/to/my/directives > > to include your directive directories. > > I will run some tests to verify whether there are any issues with this. > > Also note that you can also manually 'require' any files that you want > if you do it after you require 'masterview'. This will allow you to > manually load any directives anywhere in your path including inside of > gems. They simply have to be done after masterview though so that > MasterView will become aware of them as they load. > > Jeff > From djlewis at acm.org Thu Jul 6 01:05:41 2006 From: djlewis at acm.org (Deb Lewis) Date: Wed, 5 Jul 2006 22:05:41 -0700 Subject: [Masterview-users] Urgent Help! - User directives no longer functioning in 0.2.2 In-Reply-To: <3df642dd0607051118q2e57ac15y4fe6e6c9e03efeb3@mail.gmail.com> Message-ID: <20060706050546.GJPE985.fed1rmmtao12.cox.net@DLI92cx797990> Ed - apologies, we didn't make the config-loading change clear enough in the upgrade notes s.t. you now *had* to append your custom directives dir to the config.directive_paths. Dropping out autoloading from vendor/plugins/masterview/directives was a side effect of reworking where and how user configuration and customization gets done. Basic philosophy: your app settings and custom directives should live in your "own space", not in vendor/plugins which really ought to be black-box stuff that's just installed and used. When we made this change as part of the 0.2.0 release, it wasn't quite clear yet where the "right" place to automatically look for user directives was. These are code entities, so config/masterview didn't seem like the right place. Somewhere in app directory makes more sense, but we weren't quite sure at that point how things were best organized given other changes going on at the same time related to where template files should be located. I think we're now clear that the standard place for template files is in the usual rails app/views directory, with direct compilation into the rails view cache just like .rhtml, rather than in a separate dir such as app/masterview/templates as we'd explored in some earlier versions of the system. Given that templates live in app/views, I think the right place to look for any app custom directives for a rails app is in an app/masterview/directives directory. In the new 0.2.3 release that was just published today, if that directory is found it will be automatically appended to the MasterView directives load path, along with the builtin directives that ship with MV. So... suggest you move your directive impls to app/masterview/directives, then you don't need any special path additions in your MV config (though dup registration is benign if there) or manual directive registration. In progress for next release: support for alternate namespaces for custom directives, so they aren't forced to share the mv: namespace prefix. Also better API doc and a developer's guide for directive implementors. ~ Deb P.S. the new 0.2.3 release has new config settings to allow alt locations for img/stylesheet assets, per some of the issues you raised, so that .html templates can reference co-located design-time copies of those resources and have paths mapped properly to the public dir files. I use that to keep a placeholder stylesheet in my app/views directory that's referenced from my templates, so I don't have to use ugly ../../../public/stylesheet/xxx refs (those are actually still around, but hidden in one place in the colocated stylesheet rather than cluttering up all my .html docs) -----Original Message----- From: Ed Howland [mailto:ed.howland at gmail.com] Sent: Wednesday, July 05, 2006 11:18 AM To: Jeff Barczewski Cc: masterview-users at rubyforge.org; djlewis at acm.org Subject: Re: Urgent Help! - User directives no longer functioning in 0.2.2 Thanks Jeff. I got confused by the masterview_plugin generator which when I ran it created 'vendor/plugins/masterview/directives' which was where I installed them previously. Since that option was commented out, I assumed it still picked up any there and that you could add additional ones in the settings. I suggest that you make a note of this in the announcement, since others may run into this as well. Also, I never explicitly require 'masterview' anywhere. Are you suggesting this in one of the normal Rails configuration files? Or in vendor/plugins/masterview/init.rb? Thanks Ed On 7/5/06, Jeff Barczewski wrote: > We didn't intentionally remove user level directives from the release. > We consider it a benefit to allow user created directives. > > I would guess that since the newer version uses new configuration of > how those user directive paths are specified that this is what broke > things for you. > > Check your config/masterview/settings.rb that you have specified > config.directive_paths << /path/to/my/directives > > to include your directive directories. > > I will run some tests to verify whether there are any issues with this. > > Also note that you can also manually 'require' any files that you want > if you do it after you require 'masterview'. This will allow you to > manually load any directives anywhere in your path including inside of > gems. They simply have to be done after masterview though so that > MasterView will become aware of them as they load. > > Jeff > > > On 7/5/06, Ed Howland wrote: > > After upgrading to 0.2.2, my directives in > > vendor/plugins/masterview/directives no longer function. > Scanned all > > the documentation and could not find _any_ information on user > > created directives. > > > > Reading the code itself, there seems to be 2 commented out sections. > > One refers to app/masterview/directives and the other refers to > > config/masterview/directives. Seems to be a lot of TODO commentary. > > > > Why were user directives disabled in this release and no > > notification given? Is there a work around? I desperately need to > > get my code working again. > > > > Thanks > > > > Ed > > > > -- > > Ed Howland > > http://greenprogrammer.blogspot.com > > > > -- Ed Howland http://greenprogrammer.blogspot.com From ed.howland at gmail.com Thu Jul 6 18:41:26 2006 From: ed.howland at gmail.com (Ed Howland) Date: Thu, 6 Jul 2006 17:41:26 -0500 Subject: [Masterview-users] Example for mv:block Message-ID: <3df642dd0607061541m4a0695bbr1dd971159c053840@mail.gmail.com> If you knew me, you would know I am all about examples. There is no clearer way, IMO, of expressing the intent of a library method than with an example(s). But examples are sometimes hard to do, at least to do right. Check the win32 API docs for examples of not done right examples. That said, it took a little bit to wrap my head around mv:block, at least from the example. I got the intent of the directive, but the example left me wanting. That said, I'd like to propose this version, modified from the original: (Sorry if it wraps wrong in the email)
foobar1
foobar2
foobar3
becomes
<% products.each do |product| %>
<%= product.desc %>
<% end %>
What struck me was that you'd want to use the bound variable 'product' inside the loop, and therfore inside the content of the tag. What isn't clear to end users is that MV directives are stacked, and therefore get rendered as they are popped off the stack*. So combining directives on the same tag creates the resulting XML structure correctly. Hopefully, this example makes that clearer. Generally, I don't like to combine more than one library method in an example, and here I have 3. But MV is a different sort of a beast. Directives are not always meant to used in isolation, so the examples should reflect that. The final two mv:replace's could be left out, but I felt that in visuallizing the template HTML, the user would probably have 3 example lines in his block for verticle spacing reasons. Ed *One hopes they are stacked the correct way, regardless of the order in the directive, IOW some priority ordering is in place? -- Ed Howland http://greenprogrammer.blogspot.com From jeff.barczewski at gmail.com Fri Jul 7 12:22:41 2006 From: jeff.barczewski at gmail.com (Jeff Barczewski) Date: Fri, 7 Jul 2006 11:22:41 -0500 Subject: [Masterview-users] Example for mv:block In-Reply-To: <3df642dd0607061541m4a0695bbr1dd971159c053840@mail.gmail.com> References: <3df642dd0607061541m4a0695bbr1dd971159c053840@mail.gmail.com> Message-ID: <19cda190607070922h223c0339s24202bd01a0e7060@mail.gmail.com> Yes the example in the docs for block could definitely be improved. One might do something like
namehere pricehere
Alternatively its a better practice these days to use partials for these iterations (however using partials will currently be slower than using direct blocks like above so it is a trade off for maintainability and clean looking code). The following masterview tags will do the same thing by creating and using a _product partial.
namehere pricehere
Yes, you are right we should show the combinations of directives that make sense. Good point!! And yes, output from directives is based on the priority of the directive (if specified) so that regardless of how you declare them in the element, they get nested appropriately. Things like mv:if taking precedence over mv:block for instance. The priority if not specified is medium and then some directives override this to be higher or lower so they will nest properly. Thanks for the ideas and input!! Jeff On 7/6/06, Ed Howland wrote: > > If you knew me, you would know I am all about examples. There is no > clearer way, IMO, of expressing the intent of a library method than > with an example(s). But examples are sometimes hard to do, at least to > do right. Check the win32 API docs for examples of not done right > examples. > > That said, it took a little bit to wrap my head around mv:block, at > least from the example. I got the intent of the directive, but the > example left me wanting. That said, I'd like to propose this version, > modified from the original: (Sorry if it wraps wrong in the email) > >
>
mv:content="product.desc">foobar1
>
foobar2
>
foobar3
>
> > becomes > >
> <% products.each do |product| %> >
<%= product.desc %>
> <% end %> >
> > What struck me was that you'd want to use the bound variable 'product' > inside the loop, and therfore inside the content of the tag. What > isn't clear to end users is that MV directives are stacked, and > therefore get rendered as they are popped off the stack*. So combining > directives on the same tag creates the resulting XML structure > correctly. Hopefully, this example makes that clearer. > > Generally, I don't like to combine more than one library method in an > example, and here I have 3. But MV is a different sort of a beast. > Directives are not always meant to used in isolation, so the examples > should reflect that. The final two mv:replace's could be left out, but > I felt that in visuallizing the template HTML, the user would probably > have 3 example lines in his block for verticle spacing reasons. > > > > Ed > > *One hopes they are stacked the correct way, regardless of the order > in the directive, IOW some priority ordering is in place? > > -- > Ed Howland > http://greenprogrammer.blogspot.com > _______________________________________________ > Masterview-users mailing list > Masterview-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/masterview-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-users/attachments/20060707/dce28c38/attachment.html From ed.howland at gmail.com Fri Jul 7 13:11:47 2006 From: ed.howland at gmail.com (Ed Howland) Date: Fri, 7 Jul 2006 12:11:47 -0500 Subject: [Masterview-users] Example for mv:block In-Reply-To: <19cda190607070922h223c0339s24202bd01a0e7060@mail.gmail.com> References: <3df642dd0607061541m4a0695bbr1dd971159c053840@mail.gmail.com> <19cda190607070922h223c0339s24202bd01a0e7060@mail.gmail.com> Message-ID: <3df642dd0607071011j6b5060eci3b1040bd1e20bb1a@mail.gmail.com> On 7/7/06, Jeff Barczewski wrote: > Yes the example in the docs for block could definitely be improved. > > One might do something like > > > > > > >
nameherepricehere
> > Alternatively its a better practice these days to use partials for these > iterations (however using partials will currently be slower than using > direct blocks like above so it is a trade off for maintainability and clean > looking code). The following masterview tags will do the same thing by > creating and using a _product partial. > > > > > > >
nameherepricehere
> > > Yes, you are right we should show the combinations of directives that make > sense. Good point!! > > And yes, output from directives is based on the priority of the directive > (if specified) so that regardless of how you declare them in the element, > they get nested appropriately. Things like mv:if taking precedence over > mv:block for instance. The priority if not specified is medium and then some > directives override this to be higher or lower so they will nest properly. > > Thanks for the ideas and input!! > Glad to know I guessed that right. I like the partials idea. You should use that as an example for the gen_render directive. Somewhere the 2 directive example should be shown so people can get a feel for that. And your first table/td example should be the first example for mv:block, since it is clean. Ed > Jeff > > > On 7/6/06, Ed Howland wrote: > > > If you knew me, you would know I am all about examples. There is no > clearer way, IMO, of expressing the intent of a library method than > with an example(s). But examples are sometimes hard to do, at least to > do right. Check the win32 API docs for examples of not done right > examples. > > That said, it took a little bit to wrap my head around mv:block, at > least from the example. I got the intent of the directive, but the > example left me wanting. That said, I'd like to propose this version, > modified from the original: (Sorry if it wraps wrong in the email) > >
>
mv:content="product.desc">foobar1
>
foobar2
>
foobar3
>
> > becomes > >
> <% products.each do |product| %> >
<%= product.desc %>
> <% end %> >
> > What struck me was that you'd want to use the bound variable 'product' > inside the loop, and therfore inside the content of the tag. What > isn't clear to end users is that MV directives are stacked, and > therefore get rendered as they are popped off the stack*. So combining > directives on the same tag creates the resulting XML structure > correctly. Hopefully, this example makes that clearer. > > Generally, I don't like to combine more than one library method in an > example, and here I have 3. But MV is a different sort of a beast. > Directives are not always meant to used in isolation, so the examples > should reflect that. The final two mv:replace's could be left out, but > I felt that in visuallizing the template HTML, the user would probably > have 3 example lines in his block for verticle spacing reasons. > > > > Ed > > *One hopes they are stacked the correct way, regardless of the order > in the directive, IOW some priority ordering is in place? > > -- > Ed Howland > http://greenprogrammer.blogspot.com > _______________________________________________ > Masterview-users mailing list > Masterview-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/masterview-users > > > _______________________________________________ > Masterview-users mailing list > Masterview-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/masterview-users > > -- Ed Howland http://greenprogrammer.blogspot.com From jeff.barczewski at gmail.com Fri Jul 7 14:19:01 2006 From: jeff.barczewski at gmail.com (Jeff Barczewski) Date: Fri, 7 Jul 2006 13:19:01 -0500 Subject: [Masterview-users] Example for mv:block In-Reply-To: <3df642dd0607071011j6b5060eci3b1040bd1e20bb1a@mail.gmail.com> References: <3df642dd0607061541m4a0695bbr1dd971159c053840@mail.gmail.com> <19cda190607070922h223c0339s24202bd01a0e7060@mail.gmail.com> <3df642dd0607071011j6b5060eci3b1040bd1e20bb1a@mail.gmail.com> Message-ID: <19cda190607071119v1a716ac7ke79a5e2c5c81ae18@mail.gmail.com> Glad to know I guessed that right. I like the partials idea. You > should use that as an example for the gen_render directive. Somewhere > the 2 directive example should be shown so people can get a feel for > that. And your first table/td example should be the first example for > mv:block, since it is clean. > > Ed Yeah, and actually I goofed in my partial example, it is mv:gen_partial (since we renamed that from mv:gen_render to be clearer)
namehere pricehere
I will take your advice and we'll update the examples/documentation accordingly. Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-users/attachments/20060707/0f4beca0/attachment.html From jeff.barczewski at gmail.com Wed Jul 12 09:57:37 2006 From: jeff.barczewski at gmail.com (Jeff Barczewski) Date: Wed, 12 Jul 2006 08:57:37 -0500 Subject: [Masterview-users] Fwd: New Directives courtesy of Sergey Shalatskiy Message-ID: <19cda190607120657u3df9e767k5e2bf954c6e8b8@mail.gmail.com> MasterView users, Sergey Shalatskiy has created a few additional directives for MasterView. I planned on reviewing and adding test cases around them before adding to project, but since I got delayed in doing this I wanted to post these to the list in case so that in the meantime if anyone needed one of these they could take advantage of them. I do plan to follow through with creating test cases and making this part of the core project asap. The directives include: form_remote, hidden_field, link_to_function, silent, text_area_tag, text_field_tag (the last two might be enhancements over the core directives?) Thanks so much for Sergey to provide these. I plan to create a web app on masterview.org that would facilitate sharing of directives. This would allow people to share easily and keep the project moving in interesting directions. So if you are needing one of these directives, feel free to try out Sergey's. You can drop these into your vendor/plugins/masterview/directives folder and they should be loaded on startup. If you have any problems with any of them let me know. Then in the near future I will have tests around them and we are working on simplifying the api for directives to make it easier and more intuitive to create. Stay tuned. Jeff ---------- Forwarded message ---------- From: Sergey Shalatskiy Date: Jul 6, 2006 6:25 PM Subject: Re: MasterView generation from existing rhtml To: Jeff Barczewski Hi Jeff, I gave MasterView a try, and understood much more about it, IMHO. Also, I fixed a couple of bugs and wrote some extra directives (mainly by blatantly cutting and pasting your code). I've tested it with Ajax components, and it works fine, so I am sending you the units, if you are interested in the feedback (haven't written any tests, though). How is the new development going? Thanks, Sergey Shalatskiy ----- Original Message ----- *From:* Jeff Barczewski *To:* Sergey Shalatskiy *Sent:* Monday, June 26, 2006 7:18 PM *Subject:* Re: MasterView generation from existing rhtml I just got through chatting with the other main developer and she agrees with you, so it will be something that I will move up higher on the todo list :-) It will be a big help if people can pull in their existing site in addition to creating new pages. Make adoption easy. Thanks again for the suggestion! On 6/26/06, Sergey Shalatskiy wrote: > > > IMHO, this feature will be the deciding factor for marketing MasterView. > The > idea and original implementation are > escellent, but the ability to create html from existing files in the > application will be crucial to success of the project. > > ------------------------------ No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.4/375 - Release Date: 6/25/2006 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-users/attachments/20060712/cde31fef/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: directives.zip Type: application/zip Size: 5101 bytes Desc: not available Url : http://rubyforge.org/pipermail/masterview-users/attachments/20060712/cde31fef/attachment.zip From ed.howland at gmail.com Fri Jul 14 12:51:55 2006 From: ed.howland at gmail.com (Ed Howland) Date: Fri, 14 Jul 2006 11:51:55 -0500 Subject: [Masterview-users] Small suggestion for admin page Message-ID: <3df642dd0607140951k67f3232an6e480312d17af69c@mail.gmail.com> Can you print out the Masterview version # on the Admin page, perhaps in the "Powered by Masterview" -- Ed Howland http://greenprogrammer.blogspot.com From ed.howland at gmail.com Fri Jul 14 13:04:00 2006 From: ed.howland at gmail.com (Ed Howland) Date: Fri, 14 Jul 2006 12:04:00 -0500 Subject: [Masterview-users] Another suggestion for Admin page Message-ID: <3df642dd0607141004n23be6a88i754ae24df6058e25@mail.gmail.com> Can you include a link under the Tasks section to display loaded directives (by core, plugin and user-defined groups?) This functionality used to exist when you started WEBRick and it spit them out to the console. Ed -- Ed Howland http://greenprogrammer.blogspot.com From djlewis at acm.org Fri Jul 14 13:32:12 2006 From: djlewis at acm.org (Deb Lewis) Date: Fri, 14 Jul 2006 10:32:12 -0700 Subject: [Masterview-users] Another suggestion for Admin page In-Reply-To: <3df642dd0607141004n23be6a88i754ae24df6058e25@mail.gmail.com> Message-ID: <20060714173210.GZRB8537.fed1rmmtao04.cox.net@DLI92cx797990> Ed, Click the "View Configuration" link on the main Admin page to see the MasterView version number - it's included on the config report, along with a report on the other masterview settings. I think that's probably sufficient, not clear it's necessary to clutter the powered-by logo msg with this amt of detail. (and yes, I know the config report page needs to be fixed so it's shown in the framing context of the std admin section page layout and color scheme, I'll fix for next release 'cause the current dump on that page looks pretty tacky) Suggested addition of reporting on the installed directives is good, I'll put that on my to-do list of current work related to the directives architecture and documentation. ~ Deb -----Original Message----- From: masterview-users-bounces at rubyforge.org [mailto:masterview-users-bounces at rubyforge.org] On Behalf Of Ed Howland Sent: Friday, July 14, 2006 10:04 AM To: masterview-users at rubyforge.org Subject: [Masterview-users] Another suggestion for Admin page Can you include a link under the Tasks section to display loaded directives (by core, plugin and user-defined groups?) This functionality used to exist when you started WEBRick and it spit them out to the console. Ed -- Ed Howland http://greenprogrammer.blogspot.com _______________________________________________ From ed.howland at gmail.com Fri Jul 14 13:41:50 2006 From: ed.howland at gmail.com (Ed Howland) Date: Fri, 14 Jul 2006 12:41:50 -0500 Subject: [Masterview-users] Another suggestion for Admin page In-Reply-To: <20060714173210.GZRB8537.fed1rmmtao04.cox.net@DLI92cx797990> References: <3df642dd0607141004n23be6a88i754ae24df6058e25@mail.gmail.com> <20060714173210.GZRB8537.fed1rmmtao04.cox.net@DLI92cx797990> Message-ID: <3df642dd0607141041l4a0e3eb2p33a413c8fc38ba22@mail.gmail.com> On 7/14/06, Deb Lewis wrote: > Ed, > > Click the "View Configuration" link on the main Admin page to see the > MasterView version number - it's included on the config report, along with a > report on the other masterview settings. I think that's probably sufficient, > not clear it's necessary to clutter the powered-by logo msg with this amt of > detail. > > (and yes, I know the config report page needs to be fixed so it's shown in > the framing context of the std admin section page layout and color scheme, > I'll fix for next release 'cause the current dump on that page looks pretty > tacky) > > Suggested addition of reporting on the installed directives is good, I'll > put that on my to-do list of current work related to aring directhe directives > architecture and documentation. Thanks. Yes, that does it on the config page. Don't know why I never thought of that. I am also looking forward to the sharing directives page. There are some directives I have that overlap with what others are doing. For instance, Jeff posted a user's zip file of directives that had form_remote and text_field_tag. (The latter being very useful for search boxes.) I also did text_field_js which merges common_js_options into the options for the tag. That way you can put javascript validations, formatters on form fields. I plan to enhance this for checkbox, radio_button etc. Ed -- Ed Howland http://greenprogrammer.blogspot.com From djlewis at acm.org Fri Jul 14 15:03:27 2006 From: djlewis at acm.org (Deb Lewis) Date: Fri, 14 Jul 2006 12:03:27 -0700 Subject: [Masterview-users] Another suggestion for Admin page In-Reply-To: <3df642dd0607141041l4a0e3eb2p33a413c8fc38ba22@mail.gmail.com> Message-ID: <20060714190331.LBOZ12581.fed1rmmtao02.cox.net@DLI92cx797990> Ed wrote: >> I am also looking forward to the sharing directives page. >> There are some directives I have that overlap with what >> others are doing. For instance, Jeff posted a user's zip >> file of directives that had form_remote and text_field_tag. >> (The latter being very useful for search boxes.) I also did >> text_field_js which merges common_js_options into the options >> for the tag. Yep, I think it's time to get our namespaces for directives sorted out to handle exactly this sort of collision/merge issue with independently developed custom directives. I started looking at that last week and the basic mechanisms appear to already be in place in the rendering engine, so it's mainly a matter of specifying the architecture of how a directive developer or user defines the namespace for a directive. Hope to get that sorted out and released over the next week. It's an important piece of the foundation architecture to get settled down and leads into some interesting areas that Jeff is focusing on to make it easier to produce and deliver directives. ~ Deb From jeff.barczewski at gmail.com Wed Jul 26 15:28:05 2006 From: jeff.barczewski at gmail.com (Jeff Barczewski) Date: Wed, 26 Jul 2006 14:28:05 -0500 Subject: [Masterview-users] [ANN] MasterView rails-optimize (x)html friendly template engine - Release 0.2.4 Message-ID: <19cda190607261228h6a67244co32827d0ef321cb78@mail.gmail.com> MasterView is a rails-optimized (x)html friendly template engine plugin that provides another option to the existing rails view templates (rhtml and rxml). The main idea is to provide a template engine that would provide all the power of layouts, partials, and rails helpers but still be editable/styleable in a WYSIWYG editor. It was also a major goal that the syntax of these attribute directives be very similar to rails helpers so that one could intuitively start using MasterView with little learning curve other than knowing rails. MasterView was inspired by Amrita, Kwartz, Tapestry, Zope/PHP TAL, Liquid, and Web Objects but designed with a fresh approach and specifically targetted for rails users. Release Notes Release 0.2.4 Fixed apache2 scgi problem where masterview was not being loaded at startup. Added Interactive template console to admin pages for testing/learning how masterview directives work. Release 0.2.3 Changed default development settings for enable_admin_pages and enable_view_rhtml = true (false in production) to make it easy for new users to get up and running. Added check_box, radio_button, select, collection_select directives. Refactor attr_value parsing to be more robust taking into account nested objects. Internal rework of directive handling to support alternate namespaces for directives. Std app directives dir at rails app/masterview/directives will be automatically added to MasterView load path if exists. Release 0.2.2 Fixes problem when rails encounters exception in either compiling or involving RuntimeError in the generated rhtml. The rails TemplateError class looks at the file system for the template contents. So when generate_rhtml is false (no file is generated) rails was not able to find source and was not outputting an error page. Rails TemplateError class was extended to look at MasterView store first and then fallback to file system. More details, screenshots, and video at http://masterview.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-users/attachments/20060726/9a98fa77/attachment.html