From djlewis at acm.org Mon Jul 3 17:22:45 2006
From: djlewis at acm.org (Deb Lewis)
Date: Mon, 3 Jul 2006 14:22:45 -0700
Subject: [Masterview-devel] Bug: direct-to-erb-view-cache doesn't worth when
tmplt dir paths modified
Message-ID: <20060703212250.NHYI12581.fed1rmmtao02.cox.net@DLI92cx797990>
Jeff - Got sidetracked on my way to adding config paths for asset root refs
per pending discussion started by Ed H; was trying to figure out why my app
broke when I ran it with the new 0.2.x build with direct-to-erb. Got
"template not found" on every page.
Turns out that the problem appears to be caused when template src/dst dir
paths are modified from the default app/views.
I'm currently only using mv templates in a specific area of my site
('content' controller), so my settings.rb has:
config.template_src_dir_path = 'app/views/content'
config.template_dst_dir_path = 'app/views/content'
This worked before; broke when I ran with the new 0.2.x. Tracked down the
problem with some clues that the admin controller shows - in this config, a
template 'app/views/content/foo.html' went into the cache as 'foo.html', not
'content/foo.html' as needed by the operational system.
If I just drop out my path changes and run with the MV default (operate on
entire app/views dir), things work again.
Might be a simple fix, but I'm tabling for the moment; feel free to take a
look/fix.
Couple notes on admin controller: was trying to fix the config page to use a
layout so we can share that across the admin pages. Doesn't quite work, so
I committed the code to make it easier to return to later but it's disabled.
If you drop my draft version of the admin guy's
layouts/masterview_admin.rhtml in your own app's layouts dir and turn on the
render-with-layout version of the code, it works, but haven't found the
right hook to get into the underlying template rendering service we need
s.t. I can use the option for indicating that the template ref is an abs
path, not a rel ref in the app/views/layouts.
Suggestion: any downside to turning the template items in the main admin
list into links so it's easy to open them in a local view? We make it easy
to see the generated output now, but it's hard to get back to the original
template from whence that came.
~ Deb
From djlewis at acm.org Tue Jul 4 13:03:36 2006
From: djlewis at acm.org (Deb Lewis)
Date: Tue, 4 Jul 2006 10:03:36 -0700
Subject: [Masterview-devel] Want to revise how you did enabling admin view
in dev only
Message-ID: <20060704170339.MLDS19317.fed1rmmtao03.cox.net@DLI92cx797990>
Jeff - you did this change in a way that's a bit diff from all our other
config setting defaults (turned on only in the
masterview/environments/development.rb rather than installing default in
Configuration#initialize) and I'd like to redo to make the implementation
consistent.
Believe you were trying to maintain compatibility between 0.2.0 when we
introduced the new config mechanism, when enable-admin was always off, and
0.2.3 when we changed the default to on for dev, but I think in this case
you're working too hard at compat.
This is a benign change, worst case is that someone who really doesn't want
this in their dev setup just needs to go explicitly turn that off again.
There'll unquestionably be cases in the future when doing some fiddling in
the implementation and deviating from the standard approach in how things
are done is worth doing to provide upward compat, but I don't think in this
case it's justified.
~ Deb
From djlewis at acm.org Wed Jul 5 01:59:23 2006
From: djlewis at acm.org (Deb Lewis)
Date: Tue, 4 Jul 2006 22:59:23 -0700
Subject: [Masterview-devel] Proposed name/structure of config setting for
asset path refs
Message-ID: <20060705055929.WGUV8537.fed1rmmtao04.cox.net@DLI92cx797990>
Jeff - ok, here's a proposal for config settings to specify how to identify
the design-time directory ref prefix on image/stylesheet/js assets.
Config setting name 'template_asset_base_ref_pattern', structured as a hash
with keys :images, :stylesheets, and :javascripts per the standard naming
convention in rails public dir for these assets.
The defaults for these are your xxx_SRC_EXTRACT_REGEX's in the asset helper
directives that match ugly rel refs up from app/views to rails public dir
(../../../public/stylesheets/xxx.css)
I like one config setting with hash entries rather than proliferating a trio
of new settings names. Partly because I think we may need a matching config
setting for handling customization of the dir names in the public dir, but I
need to revisit that area of rails first to review the mechanics - you can
if you choose rename your public/stylesheets dir to, say, public/styles.
See javadoc below; will add this to the config doc and settings
example/gen-templates after names are settled on.
~ Deb
----------------------------------------------------
template_asset_base_ref_pattern
Regex pattern specifications for identifying the base directory on asset
references in a template document to convert design-time assert references
for images, stylesheets, and javascript files into relative references for
use with the standard Rails asset helper functions.
Asset types are :images, :stylesheets, :javascripts
The standard patterns match path prefixes up through public/asset-type. For
example, an mv:stylesheet_link directive of the form:
would match the standard base-dir prefix and result in:
<%= stylesheet_link_tag "mystyles" %>
----------------------------------------------------
From djlewis at acm.org Wed Jul 5 02:29:52 2006
From: djlewis at acm.org (Deb Lewis)
Date: Tue, 4 Jul 2006 23:29:52 -0700
Subject: [Masterview-devel] New DirectivesRegistry and support for multiple
directive namespaces
Message-ID: <20060705062956.IJMJ18458.fed1rmmtao10.cox.net@DLI92cx797990>
Jeff - I committed some internal rework tonight that moves around some of
the existing code related to directive loading and managing the set of known
directives to support the parser.
Ran the unit tests and my app and don't think I broke anything, but lemme
know asap if you find any problems.
There's a new MasterView.DirectivesRegistry which manages loaded-directives
registrations and acessing services for the parser. Got into that while
working through the issues of enabling support for alternate namespaces on
custom directives. Turns out we probably don't need to do much - mainly
just describe the mechanism by which a developer would do so, I think the
existing parser code is fine if alt directive namespaces suddenly appear.
Option 1 is a protocol in the directive implementation class - e.g. if you
implement class method #namespace you override the default use of the mv:
namespace. But may want alt mechanism via config settings, in addition to
or instead of a code-based mechanism, so that there's a workaround available
in the event of namespace collisions.
~ Deb
From jeff.barczewski at gmail.com Wed Jul 5 13:24:48 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 5 Jul 2006 12:24:48 -0500
Subject: [Masterview-devel] Bug: direct-to-erb-view-cache doesn't worth
when tmplt dir paths modified
In-Reply-To: <20060703212250.NHYI12581.fed1rmmtao02.cox.net@DLI92cx797990>
References: <20060703212250.NHYI12581.fed1rmmtao02.cox.net@DLI92cx797990>
Message-ID: <19cda190607051024o142dc476kdcca714b8640a113@mail.gmail.com>
Hmm.
Normally I would suggest that people simply set things to app/views for both
src and dst, even if not using the templates except in a subdirectory.
Gets back to how the relative directories are applied. If you set your root
of the content to be app/views/content then the relative paths to content
will be what gets used for direct to erb. The idea was that if you wanted to
have a tree structure outside of app/views you could but that you would want
to duplicate the directory structure in there.
Is there any reason you wouldn't want to simply set your src/dst to
app/views??
I think that is what we would strongly recommend users to do if they are
going to be using inside of the app/views tree, otherwise the first time
they add something else (different subdirectory), it won't show up either.
If you think we should support things as you have described (src/dst as
subdirectory of app/views) then I can take a look at the relative path
stuff, however it could make this a little ugly compared to what it is now.
Let me know what you think.
And on the MV admin page, did you mean creating live links to the pages off
of admin or view of the template itself? We could do either.
Jeff
On 7/3/06, Deb Lewis wrote:
>
> Jeff - Got sidetracked on my way to adding config paths for asset root
> refs
> per pending discussion started by Ed H; was trying to figure out why my
> app
> broke when I ran it with the new 0.2.x build with direct-to-erb. Got
> "template not found" on every page.
>
> Turns out that the problem appears to be caused when template src/dst dir
> paths are modified from the default app/views.
>
> I'm currently only using mv templates in a specific area of my site
> ('content' controller), so my settings.rb has:
>
> config.template_src_dir_path = 'app/views/content'
> config.template_dst_dir_path = 'app/views/content'
>
> This worked before; broke when I ran with the new 0.2.x. Tracked down the
> problem with some clues that the admin controller shows - in this config,
> a
> template 'app/views/content/foo.html' went into the cache as 'foo.html',
> not
> 'content/foo.html' as needed by the operational system.
>
> If I just drop out my path changes and run with the MV default (operate on
> entire app/views dir), things work again.
>
> Might be a simple fix, but I'm tabling for the moment; feel free to take a
> look/fix.
>
> Couple notes on admin controller: was trying to fix the config page to use
> a
> layout so we can share that across the admin pages. Doesn't quite work,
> so
> I committed the code to make it easier to return to later but it's
> disabled.
> If you drop my draft version of the admin guy's
> layouts/masterview_admin.rhtml in your own app's layouts dir and turn on
> the
> render-with-layout version of the code, it works, but haven't found the
> right hook to get into the underlying template rendering service we need
> s.t. I can use the option for indicating that the template ref is an abs
> path, not a rel ref in the app/views/layouts.
>
> Suggestion: any downside to turning the template items in the main admin
> list into links so it's easy to open them in a local view? We make it
> easy
> to see the generated output now, but it's hard to get back to the original
> template from whence that came.
>
> ~ 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/20060705/6582a04e/attachment.html
From jeff.barczewski at gmail.com Wed Jul 5 13:52:00 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 5 Jul 2006 12:52:00 -0500
Subject: [Masterview-devel] Want to revise how you did enabling admin
view in dev only
In-Reply-To: <20060704170339.MLDS19317.fed1rmmtao03.cox.net@DLI92cx797990>
References: <20060704170339.MLDS19317.fed1rmmtao03.cox.net@DLI92cx797990>
Message-ID: <19cda190607051052k2687434bp643d2eb4576430d9@mail.gmail.com>
Sounds fine Deb, I guess I wasn't sure the best way to do this, but if you
want to fix it up, then I'll take note of how I should have made the change
for consistency. I didn't realize we had any other development defaults in
the system, so that's why I made the change the way I did. If you already
had a plan and way to handle that, then I think we should use your approach.
On 7/4/06, Deb Lewis wrote:
>
> Jeff - you did this change in a way that's a bit diff from all our other
> config setting defaults (turned on only in the
> masterview/environments/development.rb rather than installing default in
> Configuration#initialize) and I'd like to redo to make the implementation
> consistent.
>
> Believe you were trying to maintain compatibility between 0.2.0 when we
> introduced the new config mechanism, when enable-admin was always off, and
> 0.2.3 when we changed the default to on for dev, but I think in this case
> you're working too hard at compat.
>
> This is a benign change, worst case is that someone who really doesn't
> want
> this in their dev setup just needs to go explicitly turn that off again.
>
> There'll unquestionably be cases in the future when doing some fiddling in
> the implementation and deviating from the standard approach in how things
> are done is worth doing to provide upward compat, but I don't think in
> this
> case it's justified.
>
> ~ 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/20060705/b430ccf8/attachment.html
From jeff.barczewski at gmail.com Wed Jul 5 13:56:58 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 5 Jul 2006 12:56:58 -0500
Subject: [Masterview-devel] FW: Proposed name/structure of config
setting for asset path refs
In-Reply-To: <20060705141846.XSNE554.fed1rmmtao11.cox.net@DLI92cx797990>
References: <20060705141846.XSNE554.fed1rmmtao11.cox.net@DLI92cx797990>
Message-ID: <19cda190607051056o6748f0efvec4a696170793df3@mail.gmail.com>
Yeah, I did not get that notification. I didn't see the commit note I made
earlier either, so I will email Tom.
I like your idea for the directory registry. I too hate having a large
proliferation of new but similar settings.
On 7/5/06, Deb Lewis wrote:
>
> Jeff - I think our masterview lists are down again - did you get this msg
> I
> sent last night? And another followed with some discussion of new
> DirectiveRegistry mechanism I committed last night (moving some of the
> existing code around to prepare for handling multiple directive
> namespaces)
>
> ~ Deb
>
> -----Original Message-----
> From: Deb Lewis [mailto:djlewis at acm.org]
> Sent: Tuesday, July 04, 2006 10:59 PM
> To: 'masterview-devel at rubyforge.org'
> Subject: Proposed name/structure of config setting for asset path refs
>
> Jeff - ok, here's a proposal for config settings to specify how to
> identify
> the design-time directory ref prefix on image/stylesheet/js assets.
>
> Config setting name 'template_asset_base_ref_pattern', structured as a
> hash
> with keys :images, :stylesheets, and :javascripts per the standard naming
> convention in rails public dir for these assets.
>
> The defaults for these are your xxx_SRC_EXTRACT_REGEX's in the asset
> helper
> directives that match ugly rel refs up from app/views to rails public dir
> (../../../public/stylesheets/xxx.css)
>
> I like one config setting with hash entries rather than proliferating a
> trio
> of new settings names. Partly because I think we may need a matching
> config
> setting for handling customization of the dir names in the public dir, but
> I
> need to revisit that area of rails first to review the mechanics - you can
> if you choose rename your public/stylesheets dir to, say, public/styles.
>
> See javadoc below; will add this to the config doc and settings
> example/gen-templates after names are settled on.
>
> ~ Deb
>
> ----------------------------------------------------
> template_asset_base_ref_pattern
>
> Regex pattern specifications for identifying the base directory on asset
> references in a template document to convert design-time assert references
> for images, stylesheets, and javascript files into relative references for
> use with the standard Rails asset helper functions.
>
> Asset types are :images, :stylesheets, :javascripts
>
> The standard patterns match path prefixes up through public/asset-type.
> For
> example, an mv:stylesheet_link directive of the form:
>
> href="../../../public/stylesheets/mystyles.css" mv:stylesheet_link="" />
>
> would match the standard base-dir prefix and result in:
>
> <%= stylesheet_link_tag "mystyles" %>
>
> ----------------------------------------------------
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060705/c9bf609b/attachment.html
From jeff.barczewski at gmail.com Wed Jul 5 14:43:06 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 5 Jul 2006 13:43:06 -0500
Subject: [Masterview-devel] Once we get the enable_admin_pages config for
dev set properly, I would like to do a release if that's ok
Message-ID: <19cda190607051143ha0916b6k20a82ed2795844f4@mail.gmail.com>
Deb,
Once we get the enable_admin_pages config for dev set properly (which if you
will show me how to best do this for consistency then I will know for
future), I would like to do a release if that's ok. I would like to get the
admin dev fix out as well as an upgrade of the attr_value parsing which was
being done by a very limited regex and the new directives (check_box,
radio_button, select, collection_select).
Not a huge release, but a decent number of things to get out there for
people to use.
So let me know how we fix the enable_admin_pages to be true for dev (without
doing it in development.rb like I did) and if there is anything else you
want in the release let me know. Then I can get that out.
Thanks,
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060705/43606cb4/attachment-0001.html
From jeff.barczewski at gmail.com Wed Jul 5 14:49:43 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 5 Jul 2006 13:49:43 -0500
Subject: [Masterview-devel] New DirectivesRegistry and support for
multiple directive namespaces
In-Reply-To: <20060705062956.IJMJ18458.fed1rmmtao10.cox.net@DLI92cx797990>
References: <20060705062956.IJMJ18458.fed1rmmtao10.cox.net@DLI92cx797990>
Message-ID: <19cda190607051149h3d887ac8i3f18289ab7b38006@mail.gmail.com>
Sounds good. I will take a look at the changes, but they seemed to be
working fine for my tests and app.
I think the namespace class impl is fine for now, we can always get more
complicated if we need to later.
On 7/5/06, Deb Lewis wrote:
>
> Jeff - I committed some internal rework tonight that moves around some of
> the existing code related to directive loading and managing the set of
> known
> directives to support the parser.
>
> Ran the unit tests and my app and don't think I broke anything, but lemme
> know asap if you find any problems.
>
> There's a new MasterView.DirectivesRegistry which manages
> loaded-directives
> registrations and acessing services for the parser. Got into that while
> working through the issues of enabling support for alternate namespaces on
> custom directives. Turns out we probably don't need to do much - mainly
> just describe the mechanism by which a developer would do so, I think the
> existing parser code is fine if alt directive namespaces suddenly appear.
>
> Option 1 is a protocol in the directive implementation class - e.g. if you
> implement class method #namespace you override the default use of the mv:
> namespace. But may want alt mechanism via config settings, in addition to
> or instead of a code-based mechanism, so that there's a workaround
> available
> in the event of namespace collisions.
>
> ~ 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/20060705/567938e7/attachment.html
From djlewis at acm.org Wed Jul 5 16:31:30 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 5 Jul 2006 13:31:30 -0700
Subject: [Masterview-devel] Once we get the enable_admin_pages config
for dev set properly, I would like to do a release if that's ok
In-Reply-To: <19cda190607051143ha0916b6k20a82ed2795844f4@mail.gmail.com>
Message-ID: <20060705203135.QWDC27857.fed1rmmtao08.cox.net@DLI92cx797990>
Jeff - should be all set, actually - that went in with my submission last
night because it was too hard to untangle from the other stuff I wanted to
get committed, so I just went ahead and did it on the cheerful assumption
that you'd go along with the change.
Believe I got all the examples, generator templates, and config doc updated,
but you can recheck with a fresh pair of eyes to make sure I didn't miss
anything.
BTW, my idea for linking directly to the template file from the MV admin
page was to just change the current left col entries with the names of the
template files into links - that would open the template in browser, but if
your system setup allows its not hard to get from there to your html editor
on the file i think.
~ Deb
_____
From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com]
Sent: Wednesday, July 05, 2006 11:43 AM
To: masterview-devel at rubyforge.org; djlewis at acm.org
Subject: Once we get the enable_admin_pages config for dev set properly, I
would like to do a release if that's ok
Deb,
Once we get the enable_admin_pages config for dev set properly (which if you
will show me how to best do this for consistency then I will know for
future), I would like to do a release if that's ok. I would like to get the
admin dev fix out as well as an upgrade of the attr_value parsing which was
being done by a very limited regex and the new directives (check_box,
radio_button, select, collection_select).
Not a huge release, but a decent number of things to get out there for
people to use.
So let me know how we fix the enable_admin_pages to be true for dev (without
doing it in development.rb like I did) and if there is anything else you
want in the release let me know. Then I can get that out.
Thanks,
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060705/44a78f32/attachment.html
From jeff.barczewski at gmail.com Wed Jul 5 17:50:51 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 5 Jul 2006 16:50:51 -0500
Subject: [Masterview-devel] Once we get the enable_admin_pages config
for dev set properly, I would like to do a release if that's ok
In-Reply-To: <20060705203135.QWDC27857.fed1rmmtao08.cox.net@DLI92cx797990>
References: <19cda190607051143ha0916b6k20a82ed2795844f4@mail.gmail.com>
<20060705203135.QWDC27857.fed1rmmtao08.cox.net@DLI92cx797990>
Message-ID: <19cda190607051450i771c3910m3eed81771227a92c@mail.gmail.com>
Wonderful!
Lets think about the admin page a little before put more links,
theoretically we could do several things, go to actual page in system, open
file in browser, view source in browser (like we do for rhtml), edit source
in browser (which would be really useful if we ever get to having files
stored in database). Obviously need more security if allowing editing. So
let's ponder on that and think what would be most useful of all those
options. Just want to put the right options that would really be useful.
On 7/5/06, Deb Lewis wrote:
>
> Jeff - should be all set, actually - that went in with my submission last
> night because it was too hard to untangle from the other stuff I wanted to
> get committed, so I just went ahead and did it on the cheerful assumption
> that you'd go along with the change.
>
> Believe I got all the examples, generator templates, and config doc
> updated, but you can recheck with a fresh pair of eyes to make sure I didn't
> miss anything.
>
> BTW, my idea for linking directly to the template file from the MV admin
> page was to just change the current left col entries with the names of the
> template files into links - that would open the template in browser, but if
> your system setup allows its not hard to get from there to your html editor
> on the file i think.
>
> ~ Deb
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060705/53d92846/attachment.html
From jeff.barczewski at gmail.com Wed Jul 5 18:03:12 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 5 Jul 2006 17:03:12 -0500
Subject: [Masterview-devel] Bug: direct-to-erb-view-cache doesn't worth
when tmplt dir paths modified
In-Reply-To: <19cda190607051024o142dc476kdcca714b8640a113@mail.gmail.com>
References: <20060703212250.NHYI12581.fed1rmmtao02.cox.net@DLI92cx797990>
<19cda190607051024o142dc476kdcca714b8640a113@mail.gmail.com>
Message-ID: <19cda190607051503n47bad00albf0ecd5a7d9c64a0@mail.gmail.com>
Just to add to the previous comment.
Currently when using direct to erb, the dst is ignored since it only uses
the relative path for things.
If we make the hard assumption that whatever src is specified is the root of
masterview html then what we have today works in direct to erb mode. Kind of
like what we were saying before that if you use app/masterview as your root,
then underneath that you would have
app/masterview/controllername/action.html. I think it would be best to steer
people away from situations like you came up with app/views/content src and
dst. Dst should always be the root of view, src should always be the root of
your source tree (although one can develop a mirrored structure if one
chooses to store those outside of app/views).
Does this make sense?
I am just seeing all sorts of other issues and headaches if we go down that
path.
On 7/5/06, Jeff Barczewski wrote:
>
> Hmm.
>
> Normally I would suggest that people simply set things to app/views for
> both src and dst, even if not using the templates except in a subdirectory.
>
> Gets back to how the relative directories are applied. If you set your
> root of the content to be app/views/content then the relative paths to
> content will be what gets used for direct to erb. The idea was that if you
> wanted to have a tree structure outside of app/views you could but that you
> would want to duplicate the directory structure in there.
>
> Is there any reason you wouldn't want to simply set your src/dst to
> app/views??
>
> I think that is what we would strongly recommend users to do if they are
> going to be using inside of the app/views tree, otherwise the first time
> they add something else (different subdirectory), it won't show up either.
>
> If you think we should support things as you have described (src/dst as
> subdirectory of app/views) then I can take a look at the relative path
> stuff, however it could make this a little ugly compared to what it is now.
> Let me know what you think.
>
> And on the MV admin page, did you mean creating live links to the pages
> off of admin or view of the template itself? We could do either.
>
> Jeff
>
>
>
>
>
> On 7/3/06, Deb Lewis wrote:
> >
> > Jeff - Got sidetracked on my way to adding config paths for asset root
> > refs
> > per pending discussion started by Ed H; was trying to figure out why my
> > app
> > broke when I ran it with the new 0.2.x build with direct-to-erb. Got
> > "template not found" on every page.
> >
> > Turns out that the problem appears to be caused when template src/dst
> > dir
> > paths are modified from the default app/views.
> >
> > I'm currently only using mv templates in a specific area of my site
> > ('content' controller), so my settings.rb has:
> >
> > config.template_src_dir_path = 'app/views/content'
> > config.template_dst_dir_path = 'app/views/content'
> >
> > This worked before; broke when I ran with the new 0.2.x. Tracked down
> > the
> > problem with some clues that the admin controller shows - in this
> > config, a
> > template 'app/views/content/foo.html' went into the cache as ' foo.html',
> > not
> > 'content/foo.html' as needed by the operational system.
> >
> > If I just drop out my path changes and run with the MV default (operate
> > on
> > entire app/views dir), things work again.
> >
> > Might be a simple fix, but I'm tabling for the moment; feel free to take
> > a
> > look/fix.
> >
> > Couple notes on admin controller: was trying to fix the config page to
> > use a
> > layout so we can share that across the admin pages. Doesn't quite work,
> > so
> > I committed the code to make it easier to return to later but it's
> > disabled.
> > If you drop my draft version of the admin guy's
> > layouts/masterview_admin.rhtml in your own app's layouts dir and turn on
> > the
> > render-with-layout version of the code, it works, but haven't found the
> > right hook to get into the underlying template rendering service we need
> >
> > s.t. I can use the option for indicating that the template ref is an abs
> > path, not a rel ref in the app/views/layouts.
> >
> > Suggestion: any downside to turning the template items in the main admin
> > list into links so it's easy to open them in a local view? We make it
> > easy
> > to see the generated output now, but it's hard to get back to the
> > original
> > template from whence that came.
> >
> > ~ 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/20060705/bbd657e0/attachment-0001.html
From jeff.barczewski at gmail.com Wed Jul 5 18:25:37 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 5 Jul 2006 17:25:37 -0500
Subject: [Masterview-devel] Couple ideas for MasterView - interactive
parsing page, using MV for static sites as well
Message-ID: <19cda190607051525s71471461yf6279e1d49d3bfd0@mail.gmail.com>
Just a couple ideas I had that I thought I would share
One thing that will make it easier to experiment and understand MasterView
is if I provide an interactive parsing page from the admin pages.
This could basically be a screen with a text area that you can put in
template html and click parse and it will show you the resultant rhtml
outputs. It would be designed that you could easily change something and
then resubmit allowing you to iteratively try things and learn. Another
simple thing we can do is to allow that page to have access to a bunch of
samples as well, so clicking on a link for the text_field directive might
give you a nice example for that all ready to run and edit. So this way we
can have an interactive help so people can learn and get comfortable with
the syntax. Just a simple controller and view is all that is needed to make
this work, we have all the rest of the plumbing.
Second idea, MasterView could also be great for maintaining static sites too
since the rebuild recreates all the pages using any shared layouts and
partials. I hadn't thought about it in that way, but since the templates are
full html copies of the pages, they would work well in a static site. No
need to use a rails app and walk the tree to generate html. We could do this
for our documentation pages, although the directives seem to be saying use a
db, everything else is pretty static.
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060705/392fc536/attachment.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-devel] [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-devel/attachments/20060705/89ca8c3f/attachment.html
From djlewis at acm.org Thu Jul 6 01:28:33 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 5 Jul 2006 22:28:33 -0700
Subject: [Masterview-devel] Couple ideas for MasterView - interactive
parsing page, using MV for static sites as well
In-Reply-To: <19cda190607051525s71471461yf6279e1d49d3bfd0@mail.gmail.com>
Message-ID: <20060706052837.YBGF9833.fed1rmmtao09.cox.net@DLI92cx797990>
> > Second idea, MasterView could also be great for maintaining static sites
too
>> since the rebuild recreates all the pages using any shared layouts and
partials. I
>> hadn't thought about it in that way, but since the templates are full
html copies
>> of the pages, they would work well in a static site. No need to use a
rails app
>> and walk the tree to generate html. We could do this for our
documentation pages,
>> although the directives seem to be saying use a db, everything else is
pretty static.
Yes, that's kind of the way I'm using MV right now for some things, just
trying to make it easier to shift some existing static site content into
rails and leverlage a framework that eliminates the problem of manually
duplicating framing layouts and nav elements across a set of pages.
Which is... exactly what we're doing with our own MV docs. That's been one
of my backburner projects, to try using MV on its own doc pages so we can
effectively use layouts and offline generation of the static set of pages
published in doc.
This would actually be a good demonstration of MV's versatility and provide
an example of using it outside rails while still exploiting some of the
power of rails and ruby facilities. We should put this on our todo list!
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060706/5289c1c7/attachment.html
From djlewis at acm.org Thu Jul 6 01:28:33 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 5 Jul 2006 22:28:33 -0700
Subject: [Masterview-devel] Bug: direct-to-erb-view-cache doesn't worth
when tmplt dir paths modified
In-Reply-To: <19cda190607051024o142dc476kdcca714b8640a113@mail.gmail.com>
Message-ID: <20060706052839.YBHU9833.fed1rmmtao09.cox.net@DLI92cx797990>
Jeff - thanks for the explanations of some of your thinking. Let'd not do
anything right now about this - my config change to restrict MV template
processing to specific subdir of my app/views can be considered a side
effect of earlier versions when we were generating .rhtml files back into
views. I don't think it's that interesting now that we compile directly
into the view cache, so unless there's issue such as perf that would lead
you to want to restrict the template checking I'd say leave it be.
I changed my config back to leave the default app/views as the template
src/dst dir settings and I'm once again a happy masterview user.
This would be a good for the "tips and troubleshooting" doc that we need to
write one of these days, though - someone might run into this and it's quite
baffling, took me several hours to hunt down the problem.
Side note: we'd briefly kicked around some thoughts on whether it might be
important to be able to specify some of the config settings on multiple MIO
trees vs. the single MIO structure that we currently have. Was thinking
about that and I'm informally convinced that it would be fairly do-able
without breaking the existing config protocol if we ever wanted to do so.
To support multiple MIO trees, existing protocol would remain and map behind
the scenes to the "primary" MIO tree, with some additional protocol provided
to allow adding and configuring options for additional sections.
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060706/05ebd046/attachment.html
From djlewis at acm.org Thu Jul 6 11:24:53 2006
From: djlewis at acm.org (Deb Lewis)
Date: Thu, 6 Jul 2006 08:24:53 -0700
Subject: [Masterview-devel] Once we get the enable_admin_pages config
for dev set properly, I would like to do a release if that's ok
Message-ID: <20060706152457.MDS22974.fed1rmmtao01.cox.net@DLI92cx797990>
agree, let's play with the idea a bit further before deciding what makes
sense, since you've got some other good ideas in this area as well about
adding interactive parsing, providing links to samples, etc
~ Deb
_____
From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com]
Sent: Wednesday, July 05, 2006 2:51 PM
To: djlewis at acm.org; masterview-devel at rubyforge.org
Subject: Re: [Masterview-devel] Once we get the enable_admin_pages config
for dev set properly, I would like to do a release if that's ok
Wonderful!
Lets think about the admin page a little before put more links,
theoretically we could do several things, go to actual page in system, open
file in browser, view source in browser (like we do for rhtml), edit source
in browser (which would be really useful if we ever get to having files
stored in database). Obviously need more security if allowing editing. So
let's ponder on that and think what would be most useful of all those
options. Just want to put the right options that would really be useful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060706/5998687c/attachment.html
From jeff.barczewski at gmail.com Thu Jul 6 12:08:35 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Thu, 6 Jul 2006 11:08:35 -0500
Subject: [Masterview-devel] configuring multiple MIO
Message-ID: <19cda190607060908o2e2be000mb600eac4c3260204@mail.gmail.com>
Sounds like a good approach.
On 7/6/06, Deb Lewis wrote:
>
> Side note: we'd briefly kicked around some thoughts on whether it might
> be important to be able to specify some of the config settings on multiple
> MIO trees vs. the single MIO structure that we currently have. Was thinking
> about that and I'm informally convinced that it would be fairly do-able
> without breaking the existing config protocol if we ever wanted to do so.
> To support multiple MIO trees, existing protocol would remain and map behind
> the scenes to the "primary" MIO tree, with some additional protocol provided
> to allow adding and configuring options for additional sections.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060706/625d54ae/attachment-0001.html
From jeff.barczewski at gmail.com Thu Jul 6 12:19:42 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Thu, 6 Jul 2006 11:19:42 -0500
Subject: [Masterview-devel] Created a first version of the interactive
parsing/rendering admin page
Message-ID: <19cda190607060919l224340fdo35419e9ab3543c61@mail.gmail.com>
I created a first version of the interactive rendering/parsing admin page
and committed. It currently lives off the main admin page with a link called
Interactive Render. Clicking on that takes you to a page where you can type
in some MV html and click render will show you on the same page below all
the rhtml that it would render.
I also created some sample that show up on the left side bar which if you
click on them, they populate the text area and submit showing you the
render. You can then edit the sample and re-render.
We can probably dress things up a little and include more description in the
page, but I wanted to at least get something up so you could see what I had
in mind and we could flush it out further.
The samples currently live in extras/sample_templates.rb (I couldn't decide
on the best place to put this so if you have a better idea we can move it).
The syntax of the sample_templates.rb isn't the greatest (might be able to
improve it), but it allows one to create categories of examples, and then in
each category, a hash of examples each with a description and the template
text. We can put examples for each of the directives and some common usage
patterns in there.
I need to still improve handling of bad template text but otherwise it is
functional.
Let me know what you think.
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060706/4b93a51c/attachment.html
From djlewis at acm.org Thu Jul 6 16:45:29 2006
From: djlewis at acm.org (Deb Lewis)
Date: Thu, 6 Jul 2006 13:45:29 -0700
Subject: [Masterview-devel] configuring multiple MIO
In-Reply-To: <19cda190607060908o2e2be000mb600eac4c3260204@mail.gmail.com>
Message-ID: <20060706204536.BSKC554.fed1rmmtao11.cox.net@DLI92cx797990>
good then - so I think we don't invest any further effort on thinking about
or handling this case until a legit need to handle finer-grained
associations between config settings and directory areas arises. As long as
we're reasonably convinced that we *could* do so without causing breakage to
existing usage - defer until needed!
YAGNI!
http://xp.c2.com/YouArentGonnaNeedIt.html
http://www.artima.com/weblogs/viewpost.jsp?thread=36529
http://en.wikipedia.org/wiki/YAGNI
~ Deb
_____
From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com]
Sent: Thursday, July 06, 2006 9:09 AM
To: djlewis at acm.org; masterview-devel at rubyforge.org
Subject: Re: configuring multiple MIO
Sounds like a good approach.
On 7/6/06, Deb Lewis wrote:
Side note: we'd briefly kicked around some thoughts on whether it might be
important to be able to specify some of the config settings on multiple MIO
trees vs. the single MIO structure that we currently have. Was thinking
about that and I'm informally convinced that it would be fairly do-able
without breaking the existing config protocol if we ever wanted to do so.
To support multiple MIO trees, existing protocol would remain and map behind
the scenes to the "primary" MIO tree, with some additional protocol provided
to allow adding and configuring options for additional sections.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060706/ffc86345/attachment.html
From jeff.barczewski at gmail.com Fri Jul 7 11:05:34 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Fri, 7 Jul 2006 10:05:34 -0500
Subject: [Masterview-devel] MasterView generation from existing rhtml
In-Reply-To: <007f01c6a153$75ab35b0$3e01a8c0@sergeyl>
References: <0e5401c698d9$b2aff900$0402a8c0@sergeyl>
<19cda190606252222s37b821edk2841f541ddc08abd@mail.gmail.com>
<0e6201c698f1$f4e53480$0402a8c0@sergeyl>
<19cda190606260930u31de6dfcx523aa7c142fcafdb@mail.gmail.com>
<000b01c69963$f00aa7c0$3e01a8c0@sergeyl>
<19cda190606261618r3a44f874g95c649da55820b4d@mail.gmail.com>
<007f01c6a153$75ab35b0$3e01a8c0@sergeyl>
Message-ID: <19cda190607070805l317f3e22yfdf41c272e599533@mail.gmail.com>
Wonderful! Thanks I will take a look at your directives and incorporate
them. We are in the process of simplifying the directive API so it will be
easier and more intuitive as well as working on documentation and such.
Will be looking at the reverse engineering feature after that.
I appreciate your time and for submitting your code!
Thanks,
Jeff
On 7/6/06, Sergey Shalatskiy wrote:
>
> 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-devel/attachments/20060707/01c572e1/attachment.html
From jeff.barczewski at gmail.com Fri Jul 7 18:45:49 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Fri, 7 Jul 2006 17:45:49 -0500
Subject: [Masterview-devel] Proposed DSL for creating directives
Message-ID: <19cda190607071545h1ace05bay90973b4713c578cc@mail.gmail.com>
Deb,
Here is a first draft of a DSL for creating directives which should clean up
the API considerably, let me know what you think
class MyDirective < DirectiveBase
event :etag do |e|
e.arg :object # get arg[0] from parse(attr_value) and assign it to
@object
e.arg :method, :quote_simple_string => true # get arg[1] from
parse(attr_value) and if is not already quoted and is simple string then
quote it, store in @method
e.arg :options, :optional_default = {} # get arg[2] from
parse(attr_value), it is optional, but if we need to add it to outgoing arg
list then we can use {} for default if nil to @options
e.arg :html_options, :merge => [Common, :rows, :cols] # get arg[3] from
parse(attr_value), merge in common html attributes and rows and cols to
@html_options
# do more business logic here, use e.content, e.yield() and other
DirectiveBase methods
e.erb 'text_area', args(:object, :method, :options, :html_options) #
renders a <%= text_area ARGS_HERE %> it builds the args, joining with comma,
eliminating if nil unless an arg after it is not nil in which case it will
use the optional_default.
end
Other methods
e.erb_code 'a = a + 1' # generates <% a = a + 1 %>
e.render 'hello world' # generates hello world
Also other methods on e.arg for manipulating the data
e.arg :foo {|o| o+'bar' } # manipulate arg[x] by concatenating 'bar' to it
and then finally store it in @foo, you could obviously do other things with
the data
e.arg :foo { e.content } # override the arg with element content and store
in @foo, link_tag uses something like this to allow users to enter link text
to be consistent with rails helpers, but then overrides it with whatever was
in the element text.
The basic idea is to wrap up much of the repetive work around building
directives into something simple yet allow custom things to be done as
necessary.
Much of the tediousness is simply parsing out args from the attr_value,
quoting if necessary, merging in html options and other simple logic.
Finally we build up output to write outputting <%= %> and joining together
args, accounting for the fact that some args might be missing and if later
args are suddenly non-empty because of a merge, then we need to output good
defaults for the nil previous ones.
So I was kind of patterning this dsl off of what we need to do and how rake
and active record migrations dsl's work.
It seems clearer to me what happens doing this and much of the monkey
business is abstacted away using a few key words.
Let me know what you think.
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060707/378e4a5a/attachment.html
From djlewis at acm.org Sat Jul 8 16:07:17 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sat, 8 Jul 2006 13:07:17 -0700
Subject: [Masterview-devel] Proposed DSL for creating directives
In-Reply-To: <19cda190607071545h1ace05bay90973b4713c578cc@mail.gmail.com>
Message-ID: <20060708200719.OHTA12581.fed1rmmtao02.cox.net@DLI92cx797990>
Jeff - good stuff, I'll have to time to get back to working on directives
tomorrow and will give you some feedback after I've had a chance to play
around with the proposal a bit.
[been pretty swamped all week, but finally getting through the initial
ramp-up learning curve for the company I've just started working for, so
should be able to have more time again over the next week to get back to
working on some of my rails stuff and MV]
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060708/5108a1a2/attachment-0001.html
From jeff.barczewski at gmail.com Wed Jul 12 10:07:38 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 12 Jul 2006 09:07:38 -0500
Subject: [Masterview-devel] MasterView directives - proposal single file
format to contain code and all necessary docs, examples,
category, etc.
Message-ID: <19cda190607120707u105cbf9dk16e07459da8bee1f@mail.gmail.com>
Deb,
I was thinking about how to approach sharing of directives and everything
that involved around that.
I want to make this as easy as possible both for users and for us.
So with that in mind, it seems like a single file format for directives
would be the easiest. In that single ruby file we would have the directive
code and all the other necessary information to add it to the master list.
For instance in the rdoc it would have information about the directive.
Inside that might be example code on how to use it which could be
automatically put on the interactive test page. We could include a category
in the directive which we can use to group directives together much like you
have done for the docs.
My thinking is that if we move all the necessary information into the
directive files themselves and read it from there then we can make our docs,
interactive test page, and catalogs all dynamic. And people can upload and
submit a single ruby file and make it part of a shared online collection.
The only thing I haven't figured out is tests for the ruby directive. Those
are begging to be in a separate file unless we allow those to be bundled in
as well and then maybe not loaded at runtime but have test helper that
searches out those during test runs?? Haven't thought threw this last item
much but it would be so nice to be able to have people only submit a single
file to have everything. Gems would work too, but they are harder for people
to build.
Let's think through further and see what we can come up with.
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060712/7bc2104e/attachment.html
From jeff.barczewski at gmail.com Wed Jul 12 09:45:15 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 12 Jul 2006 08:45:15 -0500
Subject: [Masterview-devel] [Rails] (Re-)designing a CMS
In-Reply-To:
References:
Message-ID: <19cda190607120645m2099e8fah10953b1cd924dd22@mail.gmail.com>
Gijs,
Check out the MasterView plugin for rails, this sounds like it would meet
your needs nicely.
MasterView is a WYSIWYG friendly syntax inspired by PHP/Zope TAL which
allows you to take html and add attribute directives that turn plain html
into a dynamic web app. This sounds just like what you are looking for. The
syntax for the attributes is based on the rails helpers themselves and the
project is open in that you can create your own as well. In addition unlike
the other templating engines, MasterView allows you to take full advantage
of layouts, partials, helpers, and anything you could do in ERb, so you can
keep things DRY yet still be able to view/edit in a WYSIWYG browser. The
attribute directives are smart in that they inherit properties from the html
itself as well, so when you adjust style or sizes of fields, that
information gets passed through to the rails helper.
The project is open source, available on rubyforge. There is documentation,
screenshots, and video available on http://masterview.org/
If you have a chance to check the project out, be sure to let us know what
you think and if there are any ways in which we can improve the project. The
team is always looking for feedback.
Have a blessed day!
Jeff Barczewski
MasterView, project founder
http://masterview.org/
On 7/12/06, Gijs Nijholt wrote:
>
> Hello Rails-list,
>
> I'm working on a CMS in Rails.
> The company that I work for currently uses a CMS written in PHP, and I
> want to mimick it in Rails, and improve along the way.
>
> The PHP variant works with templates like this:
>
> In the root of the webdir, there are the template files, named
> cms_news.html for example.
> This page contains custom tags, in the form of definitions and
> placeholders...
> The definition tags go like:
>
>
>
> They are placed on top of the file, before the tag.
> PHP uses str_replace() to filter out these tags.
> This definition pulls its data from SQL table 't_articles'
>
> The placeholder tags define where the previously defined 'block'
> should be displayed in the page:
>
> ........html.........
>
> ........html.........
>
> This prints a list of articles according to the definition.
> The -tag (in cmsdef) adds a little editbutton, which can
> bring up a popup within which one can modify the contents of the
> block.
>
> With this functionality, it's possible to build quite a website, and
> manage it in a WYSIWYG-way.
>
> But how to approach this in Rails?
> The goals are simple, really.. I want to be able to have designers
> create regular HTML files, with a couple of special tags where they
> want to display dynamic content.
> Within the CMS interface, the site must be viewable in 'preview' and
> 'edit' mode.
> In preview-mode, the website is rendered like the world would see it.
> In edit-mode, some edit buttons appear above the dynamic spots.
>
> Should I try to mimick it as close as possible, using Ruby's File
> library and lots of gsub's?
> Or maybe there's a better way, using RHTML or Liquid, to achieve the same
> goal?
>
> It's a bit of an open question, and I'm just looking for thoughts or
> hints.
> Thanks
>
> Gijs Nijholt
> _______________________________________________
> Rails mailing list
> Rails at lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060712/6173efc4/attachment.html
From djlewis at acm.org Thu Jul 13 00:01:59 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 12 Jul 2006 21:01:59 -0700
Subject: [Masterview-devel] MasterView directives - proposal single file
format to contain code and all necessary docs, examples,
category, etc.
In-Reply-To: <19cda190607120707u105cbf9dk16e07459da8bee1f@mail.gmail.com>
Message-ID: <20060713040158.CDHI12581.fed1rmmtao02.cox.net@DLI92cx797990>
Jeff - yes, I like the direction that you're heading with a scheme so that
everything needed for a directive can be easily packaged in a single source
file.
As soon as someone has to start going through packaging and build cycles,
the "barrier to entry" goes way, way up.
I could live with, say, a 2-file approach based on a naming convention for
identifying test case to go with a directive; might even be better than
trying to bundle it all in one file, I do like having some separation of
tests from deliverables. Separate but equal - tests come alongside, but
they're not the thing itself.
Sorry I haven't made much progress this week on the directives
infrastructure I got started on; been deep in a "zope black hole" all week
for my new client. Seeing some light in the tunnel though, so hoping for a
break to get back to the fun rails stuff within a day or two. It'll be a
masterview w/e out here on the coast. (and hey, paying work after a rather
long slow period ain't so bad, I'm not complaining!)
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060712/e3cbfc9d/attachment.html
From jeff.barczewski at gmail.com Fri Jul 14 16:38:13 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Fri, 14 Jul 2006 15:38:13 -0500
Subject: [Masterview-devel] Proposed File format for directives
Message-ID: <19cda190607141338me2847f9of99714c2d6b1a7b3@mail.gmail.com>
How about something like this for the single file format for directives?
# Basic description text goes in the rdoc like normal
# more desc here
# more desc here
=begin example
A good example of various usage pattens would go here
One could demonstrate several in one html snippet
=end
=begin result
foo.bar:
<%= cat %>
<%= dog(hello) %>
=end result
class MyDirective < MasterView::DirectiveBase
def self.category # this would actually be the category the directive gets
cataloged in (if provided)
'Form Helpers'
end
def stag
end
...
end
So the thinking is that we can build our directive docs right off the source
files. We will pull the main class comments in as description text, then we
can have an example and result. The example could also automatically be made
available to the interactive test page, so it would show up as another
example link which if you click would populate it with the example text.
The self.category if exists could be used to categorize the directive so we
can put them in categories. Our directive docs have some categories now so
we could use this kind of concept to group things. The name would come from
the class name or directive name if overridden.
I haven't quite figured out how to do multiple examples since for the
interactive link I only want one. I guess we could allow multiple but I just
will take the first one for the interactive page.
Would this be easy enough to follow if people were starting from an existing
directive or template?
I think this would work out well if we can move towards reading everything
out of our directive files that will keep things in sync everywhere with no
duplication. And it allows others to upload files or download files to their
system and if we have a simple admin page which can read the available
directives on the system it can provide a live reference of every directive
installed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060714/65b66b59/attachment.html
From jeff.barczewski at gmail.com Fri Jul 14 16:40:04 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Fri, 14 Jul 2006 15:40:04 -0500
Subject: [Masterview-devel] Proposed File format for directives
In-Reply-To: <19cda190607141338me2847f9of99714c2d6b1a7b3@mail.gmail.com>
References: <19cda190607141338me2847f9of99714c2d6b1a7b3@mail.gmail.com>
Message-ID: <19cda190607141340i7e6389c4m973bee7bf23bf375@mail.gmail.com>
oops submitted before I added the version in.
Here it is with version added.
On 7/14/06, Jeff Barczewski wrote:
>
> How about something like this for the single file format for directives?
>
> # Basic description text goes in the rdoc like normal
> # more desc here
> # more desc here
>
> =begin example
>
>
> A good example of various usage pattens would go here
>
>
> One could demonstrate several in one html snippet
>
>
> =end
>
> =begin result
> foo.bar:
>
>
<%= cat %>
>
<%= dog(hello) %>
>
> =end result
>
> class MyDirective < MasterView::DirectiveBase
> def self.category # this would actually be the category the directive
> gets cataloged in (if provided)
> 'Form Helpers'
> end
>
def self.version
1.01
end
def stag
> end
>
> ...
> end
>
>
>
> So the thinking is that we can build our directive docs right off the
> source files. We will pull the main class comments in as description text,
> then we can have an example and result. The example could also automatically
> be made available to the interactive test page, so it would show up as
> another example link which if you click would populate it with the example
> text.
>
> The self.category if exists could be used to categorize the directive so
> we can put them in categories. Our directive docs have some categories now
> so we could use this kind of concept to group things. The name would come
> from the class name or directive name if overridden.
>
> I haven't quite figured out how to do multiple examples since for the
> interactive link I only want one. I guess we could allow multiple but I just
> will take the first one for the interactive page.
>
> Would this be easy enough to follow if people were starting from an
> existing directive or template?
>
> I think this would work out well if we can move towards reading everything
> out of our directive files that will keep things in sync everywhere with no
> duplication. And it allows others to upload files or download files to their
> system and if we have a simple admin page which can read the available
> directives on the system it can provide a live reference of every directive
> installed.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060714/7afdc92e/attachment-0001.html
From jeff.barczewski at gmail.com Sat Jul 15 12:32:13 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Sat, 15 Jul 2006 11:32:13 -0500
Subject: [Masterview-devel] Proposed File format for directives
In-Reply-To: <19cda190607141340i7e6389c4m973bee7bf23bf375@mail.gmail.com>
References: <19cda190607141338me2847f9of99714c2d6b1a7b3@mail.gmail.com>
<19cda190607141340i7e6389c4m973bee7bf23bf375@mail.gmail.com>
Message-ID: <19cda190607150932g322309cbi6489d8a8c489889d@mail.gmail.com>
On further consideration maybe it would be better to put all of the
description and example in class methods to make it easier to access and to
take advantage of it potentially being loaded from anywhere including gems.
If description and example are class methods then we simply iterate on the
loaded directives rather than having to read and parse files.
If the documentation for these is dynamically made available via masterview
admin pages or a new documentation controller then the need for rdoc on this
is reduced. Its all about getting good documentation and keeping it current.
And I would like to provide examples for the interactive page.
The only question is whether class methods or constants would be best
approach and whether these take up any memory footprint until needed.
So format ends up being something like
class MyDirective < MasterView::DirectiveBase
> def self.category # this would actually be the category the directive
> gets cataloged in (if provided)
> 'Form Helpers'
> end
>
def self.version
1.01
end
def stag
> end
>
> ...
> end
>
>
On 7/14/06, Jeff Barczewski wrote:
>
> oops submitted before I added the version in.
>
> Here it is with version added.
>
> On 7/14/06, Jeff Barczewski < jeff.barczewski at gmail.com> wrote:
> >
> > How about something like this for the single file format for directives?
> >
> >
> > # Basic description text goes in the rdoc like normal
> > # more desc here
> > # more desc here
> >
> > =begin example
> >
> >
> > A good example of various usage pattens would go here
> >
> >
> > One could demonstrate several in one html snippet
> >
> >
> > =end
> >
> > =begin result
> > foo.bar:
> >
> >
<%= cat %>
> >
<%= dog(hello) %>
> >
> > =end result
> >
> > class MyDirective < MasterView::DirectiveBase
> > def self.category # this would actually be the category the directive
> > gets cataloged in (if provided)
> > 'Form Helpers'
> > end
> >
>
>
> def self.version
> 1.01
> end
>
> def stag
> > end
> >
> > ...
> > end
> >
> >
> >
> > So the thinking is that we can build our directive docs right off the
> > source files. We will pull the main class comments in as description text,
> > then we can have an example and result. The example could also automatically
> > be made available to the interactive test page, so it would show up as
> > another example link which if you click would populate it with the example
> > text.
> >
> > The self.category if exists could be used to categorize the directive so
> > we can put them in categories. Our directive docs have some categories now
> > so we could use this kind of concept to group things. The name would come
> > from the class name or directive name if overridden.
> >
> > I haven't quite figured out how to do multiple examples since for the
> > interactive link I only want one. I guess we could allow multiple but I just
> > will take the first one for the interactive page.
> >
> > Would this be easy enough to follow if people were starting from an
> > existing directive or template?
> >
> > I think this would work out well if we can move towards reading
> > everything out of our directive files that will keep things in sync
> > everywhere with no duplication. And it allows others to upload files or
> > download files to their system and if we have a simple admin page which can
> > read the available directives on the system it can provide a live reference
> > of every directive installed.
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060715/35ee5d41/attachment.html
From jeff.barczewski at gmail.com Sat Jul 15 12:36:06 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Sat, 15 Jul 2006 11:36:06 -0500
Subject: [Masterview-devel] Proposed File format for directives
In-Reply-To: <19cda190607150932g322309cbi6489d8a8c489889d@mail.gmail.com>
References: <19cda190607141338me2847f9of99714c2d6b1a7b3@mail.gmail.com>
<19cda190607141340i7e6389c4m973bee7bf23bf375@mail.gmail.com>
<19cda190607150932g322309cbi6489d8a8c489889d@mail.gmail.com>
Message-ID: <19cda190607150936v6f143acdpf122fb4e1eb0bf6d@mail.gmail.com>
sorry gmail submitted again before I was done. The format using class
methods might be something like. Or we could use constants similarly if that
would be better for memory footprint. I kind of thing methods might be
lighterweight since constants might take up memory all the time.
class MyDirective < MasterView::DirectiveBase
> def self.category # this would actually be the category the directive
> gets cataloged in (if provided)
> 'Form Helpers'
> end
>
def self.version
1.01
end
def description
desc <<-END
The description goes here
more here
END
end
def example
example <<-END
A good example of various usage pattens would go here
One could demonstrate several in one html snippet
END
end
def stag
> end
>
> ...
> end
>
>
On 7/15/06, Jeff Barczewski wrote:
>
> On further consideration maybe it would be better to put all of the
> description and example in class methods to make it easier to access and to
> take advantage of it potentially being loaded from anywhere including gems.
>
> If description and example are class methods then we simply iterate on the
> loaded directives rather than having to read and parse files.
>
> If the documentation for these is dynamically made available via
> masterview admin pages or a new documentation controller then the need for
> rdoc on this is reduced. Its all about getting good documentation and
> keeping it current. And I would like to provide examples for the interactive
> page.
>
> The only question is whether class methods or constants would be best
> approach and whether these take up any memory footprint until needed.
>
> So format ends up being something like
>
>
> class MyDirective < MasterView::DirectiveBase
> > def self.category # this would actually be the category the directive
> > gets cataloged in (if provided)
> > 'Form Helpers'
> > end
> >
>
>
> def self.version
> 1.01
> end
>
>
>
> def stag
> > end
> >
> > ...
> > end
> >
> >
>
> On 7/14/06, Jeff Barczewski wrote:
> >
> > oops submitted before I added the version in.
> >
> > Here it is with version added.
> >
> > On 7/14/06, Jeff Barczewski < jeff.barczewski at gmail.com> wrote:
> > >
> > > How about something like this for the single file format for
> > > directives?
> > >
> > > # Basic description text goes in the rdoc like normal
> > > # more desc here
> > > # more desc here
> > >
> > > =begin example
> > >
> > >
> > > A good example of various usage pattens would go here
> > >
> > >
> > > One could demonstrate several in one html snippet
> > >
> > > =end result
> > >
> > > class MyDirective < MasterView::DirectiveBase
> > > def self.category # this would actually be the category the
> > > directive gets cataloged in (if provided)
> > > 'Form Helpers'
> > > end
> > >
> >
> >
> > def self.version
> > 1.01
> > end
> >
> > def stag
> > > end
> > >
> > > ...
> > > end
> > >
> > >
> > >
> > > So the thinking is that we can build our directive docs right off the
> > > source files. We will pull the main class comments in as description text,
> > > then we can have an example and result. The example could also automatically
> > > be made available to the interactive test page, so it would show up as
> > > another example link which if you click would populate it with the example
> > > text.
> > >
> > > The self.category if exists could be used to categorize the directive
> > > so we can put them in categories. Our directive docs have some categories
> > > now so we could use this kind of concept to group things. The name would
> > > come from the class name or directive name if overridden.
> > >
> > > I haven't quite figured out how to do multiple examples since for the
> > > interactive link I only want one. I guess we could allow multiple but I just
> > > will take the first one for the interactive page.
> > >
> > > Would this be easy enough to follow if people were starting from an
> > > existing directive or template?
> > >
> > > I think this would work out well if we can move towards reading
> > > everything out of our directive files that will keep things in sync
> > > everywhere with no duplication. And it allows others to upload files or
> > > download files to their system and if we have a simple admin page which can
> > > read the available directives on the system it can provide a live reference
> > > of every directive installed.
> > >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060715/ce8f2375/attachment.html
From djlewis at acm.org Sat Jul 15 12:46:42 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sat, 15 Jul 2006 09:46:42 -0700
Subject: [Masterview-devel] Proposed File format for directives
In-Reply-To: <19cda190607150932g322309cbi6489d8a8c489889d@mail.gmail.com>
Message-ID: <20060715164647.EZWX18458.fed1rmmtao10.cox.net@DLI92cx797990>
received; digesting..., will have some reactions tomorrow
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060715/0d8ad3c0/attachment.html
From jeff.barczewski at gmail.com Mon Jul 17 10:12:08 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 17 Jul 2006 09:12:08 -0500
Subject: [Masterview-devel] Another idea for the single file format for
directives
Message-ID: <19cda190607170712n1cec6588r6505b5efa7c080af@mail.gmail.com>
We could use an inner class to hold the description and examples
class MyDirective
class MetaInfo
def description
...
end
def example
...
end
end
end
or even simply a Map to hold the pieces.
Just other ideas to add to the list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060717/8e2b7520/attachment-0001.html
From JBarczewski at rgatp.com Mon Jul 17 14:40:23 2006
From: JBarczewski at rgatp.com (Barczewski, Jeff)
Date: Mon, 17 Jul 2006 13:40:23 -0500
Subject: [Masterview-devel] Should masterview assume a generate destination
of * if no mv:generate or mv:gen_partials are specified in
the template?
Message-ID:
My gmail account is down today so, sending this from my work account.
I was thinking that for beginning users that the mv:generate thing is a
brand new concept from all of the other templating systems so if they
write some templates and don't include those directives (mv:generate or
mv:gen_partial) they won't get any output and will be thinking it is
broken.
So much like rails assumes that if you don't specify a render call in
your controller that it should use the default render view, maybe MV
should assume that if you don't specify any mv:generate or
mv:gen_partial calls that we should assume a mv:generate="*". And if
their root is then we would assume that they want the content of
the body for this output so we would do essentially put this in the body
tag , since typically this will be
wrapped with a layout. If they don't lead with then we'd put the
mv:generate="*" at the root and leave out the omit_tag..
This would make it easier for people that are starting out, to get
something working especially if they have tried other similar template
libs.
The only issue I see with this is that if people have other non mv html
files in their tree (not sure why they would though since they typically
would be in public) then those would potentially generate rhtml as well.
We could make the directive configurable as to whether it is enabled,
but maybe that is overkill. If we make the assumption that either they
won't have non mv html files in their view dirs or that it doesnt matter
if some extra rhtml files are created then we it should work fine.
Ideas or thoughts?
Thanks,
Jeff
From jeff.barczewski at gmail.com Mon Jul 17 15:38:45 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 17 Jul 2006 14:38:45 -0500
Subject: [Masterview-devel] Should MV assume a generate destination if none
is provided in the template?
Message-ID: <19cda190607171238i5f7572car3dfa6b8d81eb6297@mail.gmail.com>
I was thinking that for beginning users that the mv:generate thing is a
brand new concept from all of the other templating systems so if they write
some templates and don't include those directives (mv:generate or
mv:gen_partial) they won't get any output and will be thinking it is broken.
So much like rails assumes that if you don't specify a render call in your
controller that it should use the default render view, maybe MV should
assume that if you don't specify any mv:generate or mv:gen_partial calls
that we should assume a mv:generate="*". And if their root is then we
would assume that they want the content of the body for this output so we
would do essentially put this in the body tag , since typically this will be wrapped with a layout. If they
don't lead with then we'd put the mv:generate="*" at the root and
leave out the omit_tag..
This would make it easier for people that are starting out, to get something
working especially if they have tried other similar template libs.
The only issue I see with this is that if people have other non mv html
files in their tree (not sure why they would though since they typically
would be in public) then those would potentially generate rhtml as well. We
could make the directive configurable as to whether it is enabled, but maybe
that is overkill. If we make the assumption that either they won't have non
mv html files in their view dirs or that it doesnt matter if some extra
rhtml files are created then we it should work fine.
Ideas or thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060717/88265330/attachment.html
From djlewis at acm.org Tue Jul 18 12:42:21 2006
From: djlewis at acm.org (Deb Lewis)
Date: Tue, 18 Jul 2006 09:42:21 -0700
Subject: [Masterview-devel] Should MV assume a generate destination if
none is provided in the template?
In-Reply-To: <19cda190607171238i5f7572car3dfa6b8d81eb6297@mail.gmail.com>
Message-ID: <20060718164225.RZVY985.fed1rmmtao12.cox.net@DLI92cx797990>
I think that's a good default, tho let's think through the wrinkles a bit
more just to make sure we aren't missing something about being able to
reliably do the "right" thing.
I think it's ok to assume that .html in the app/view directory is intended
by be used w/in the rendering framework. If you don't want any processing,
you should have put that file in your app/public.
But let's allow for exceptions by an "ignore me entirely" attribute: e.g.,
....
means "buzz off and leave me alone, I don't want no processing on me".
But then, yes, agree with your proposal: if a .html file in app/views which
is truly contains no output generation directives (no mv:generate or
mv:gen_partial), then mv assumes default as if you had written:
....
That's nice, gives you an easy way to pour chunks of basic content into your
site to leverage a page framing layout without any extra work.
BTW, if we don't already, suggest we interpret both mv:generate="" and
mv:generate="*" as shorthand for mv:generate={template_path}". (can't
remember if we're doing that, need to recheck the subst. code)
~ Deb
_____
From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com]
Sent: Monday, July 17, 2006 12:39 PM
To: masterview-devel at rubyforge.org; djlewis at acm.org
Subject: Should MV assume a generate destination if none is provided in the
template?
I was thinking that for beginning users that the mv:generate thing is a
brand new concept from all of the other templating systems so if they write
some templates and don't include those directives (mv:generate or
mv:gen_partial) they won't get any output and will be thinking it is broken.
So much like rails assumes that if you don't specify a render call in your
controller that it should use the default render view, maybe MV should
assume that if you don't specify any mv:generate or mv:gen_partial calls
that we should assume a mv:generate="*". And if their root is then we
would assume that they want the content of the body for this output so we
would do essentially put this in the body tag , since typically this will be wrapped with a layout. If they
don't lead with then we'd put the mv:generate="*" at the root and
leave out the omit_tag..
This would make it easier for people that are starting out, to get something
working especially if they have tried other similar template libs.
The only issue I see with this is that if people have other non mv html
files in their tree (not sure why they would though since they typically
would be in public) then those would potentially generate rhtml as well. We
could make the directive configurable as to whether it is enabled, but maybe
that is overkill. If we make the assumption that either they won't have non
mv html files in their view dirs or that it doesnt matter if some extra
rhtml files are created then we it should work fine.
Ideas or thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060718/da910b8d/attachment.html
From djlewis at acm.org Tue Jul 18 12:43:43 2006
From: djlewis at acm.org (Deb Lewis)
Date: Tue, 18 Jul 2006 09:43:43 -0700
Subject: [Masterview-devel] Another idea for the single file format for
directives
Message-ID: <20060718164346.DUPC554.fed1rmmtao11.cox.net@DLI92cx797990>
Jeff - I like the notion of having a standard DirectiveInfo meta-info class
to associate with a directive implementation, which provides a standard
approach for expressing the interesting metadata for a directive: version,
description, optional category. As you say, that then gives us a clean way
to drive other interesting tools (admin views of loaded directives, doc
generation, etc)
Not sure if I like having the example bundled into the core runtime class.
Maybe example (and even description) are better done by a sibling class,
located by convention using name derived from that of the
ModName::DirectiveClass, e.g. ModName::DirectiveClassDoc to contain
supporting doc specifications?
Similar to scheme for packaging and locating test cases - my_directive.rb +
my_directive.rb pair of files.
Also include optional attribute_name in there, so that our implementation of
the standard class method attr_name on DirectiveBase can check for override
before dropping into default_attr_name backstop. (Or maybe that just all
migrates into DirectiveInfo as method #attr_name or #attribute_name; I
prefer the longer form, actually)
I'd also like a namespace attribute in there to provide the foundation for
supporting multiple namespaces: #namespace_name. That would then be
exploited by our standard methods for forming fully-qualified attribute
names. Someone assembling a library of addons could then subclass
DirectiveInfo to install their own std namespace value and then use
MyCustomDirectiveLibraryDirectiveIinfo in their directives.
So directive protocol proposal: #directive_name returns the fully-qualified
name of the directive's attribute; #attribute_name returns the simple
attribute name, #namespace_name returns the namespace prefix qualifier.
Maybe deprecate the original #full_attr_name currently in DirectiveBase,
would like to use method names that directly reflect XML namespace
terminology for qnames.
Believe we'll also also need an override mechanism for namespaces in the MV
config options, just as xmlns markup allows the usage site to override the
creator's namespace in order to resolve namespace collisions in their
documents, but that would build on top of the basic facility.
~ Deb
_____
From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com]
Sent: Monday, July 17, 2006 7:12 AM
To: masterview-devel at rubyforge.org; djlewis at acm.org
Subject: Another idea for the single file format for directives
We could use an inner class to hold the description and examples
class MyDirective
class MetaInfo
def description
...
end
def example
...
end
end
end
or even simply a Map to hold the pieces.
Just other ideas to add to the list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060718/e19709f3/attachment-0001.html
From djlewis at acm.org Tue Jul 18 13:09:14 2006
From: djlewis at acm.org (Deb Lewis)
Date: Tue, 18 Jul 2006 10:09:14 -0700
Subject: [Masterview-devel] Another idea for the single file format
fordirectives
In-Reply-To: <20060718164346.DUPC554.fed1rmmtao11.cox.net@DLI92cx797990>
Message-ID: <20060718170918.EYLY554.fed1rmmtao11.cox.net@DLI92cx797990>
>>> Similar to scheme for packaging and locating test cases -
my_directive.rb + my_directive.rb pair of files.
ahh... that was meant to be: ... + test_my_directive.rb (or
directive_FOO_test.rb for FOO.rb, per our own existing unit test file naming
convention_
(use std prefix or suffix on the file containing the test case for the
directive,
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060718/f465b080/attachment.html
From jeff.barczewski at gmail.com Tue Jul 18 15:20:34 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Tue, 18 Jul 2006 14:20:34 -0500
Subject: [Masterview-devel] Should MV assume a generate destination if
none is provided in the template?
In-Reply-To: <20060718164225.RZVY985.fed1rmmtao12.cox.net@DLI92cx797990>
References: <19cda190607171238i5f7572car3dfa6b8d81eb6297@mail.gmail.com>
<20060718164225.RZVY985.fed1rmmtao12.cox.net@DLI92cx797990>
Message-ID: <19cda190607181220t6dc42461o5d044beb34896b9a@mail.gmail.com>
Sounds good. I think we had the generate="*" in there but would have to
double check.
On 7/18/06, Deb Lewis wrote:
>
> I think that's a good default, tho let's think through the wrinkles a bit
> more just to make sure we aren't missing something about being able to
> reliably do the "right" thing.
>
> I think it's ok to assume that .html in the app/view directory is intended
> by be used w/in the rendering framework. If you don't want any processing,
> you should have put that file in your app/public.
>
> But let's allow for exceptions by an "ignore me entirely" attribute: e.g.,
>
>
> ....
>
>
> means "buzz off and leave me alone, I don't want no processing on me".
>
> But then, yes, agree with your proposal: if a .html file in app/views
> which is truly contains no output generation directives (no
> mv:generate or mv:gen_partial), then mv assumes default as if you had
> written:
>
>
> ....
>
>
> That's nice, gives you an easy way to pour chunks of basic content into
> your site to leverage a page framing layout without any extra work.
>
> BTW, if we don't already, suggest we interpret both mv:generate="" and
> mv:generate="*" as shorthand for mv:generate={template_path}". (can't
> remember if we're doing that, need to recheck the subst. code)
>
> ~ Deb
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060718/07436e5e/attachment.html
From jeff.barczewski at gmail.com Tue Jul 18 15:34:57 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Tue, 18 Jul 2006 14:34:57 -0500
Subject: [Masterview-devel] Another idea for the single file format for
directives
In-Reply-To: <44bd0c6e.034c70f3.75df.3c33SMTPIN_ADDED@mx.gmail.com>
References: <19cda190607170712n1cec6588r6505b5efa7c080af@mail.gmail.com>
<44bd0c6e.034c70f3.75df.3c33SMTPIN_ADDED@mx.gmail.com>
Message-ID: <19cda190607181234s78558198ld294ddf1d7eb2180@mail.gmail.com>
Yeah I see where you are going. I think this is shaping up. The only concern
is how to make it easy for people to submit these via upload without
packaging. If we were doing things in a single file (or two if they have
test cases) then I think they can handle it (many won't do tests so that
means one file). Simple http file upload and they are done.
Also simple install, place the single directive file in your directory and
you are done. Your dynamic doc app will be able to pick up the docs and
examples.
So if we include this meta class in the same file along with the directive
then I think it works well, doesn't have to be an inner class just pushing
for single file (+separate test file if they have one).
If we package things up for distribution then we certainly could split
things into separate files if we wanted to, however there is something to be
said for consistency.
So what do you think. I think the meta info class has merit for all the
things described (namespace, attr name, desc, examples), however how do we
keep it simple and down to single file upload and install?
On 7/18/06, Deb Lewis wrote:
>
> Jeff - I like the notion of having a standard DirectiveInfo meta-info
> class to associate with a directive implementation, which provides a
> standard approach for expressing the interesting metadata for a directive:
> version, description, optional category. As you say, that then gives us a
> clean way to drive other interesting tools (admin views of loaded
> directives, doc generation, etc)
>
> Not sure if I like having the example bundled into the core runtime
> class. Maybe example (and even description) are better done by a sibling
> class, located by convention using name derived from that of the
> ModName::DirectiveClass, e.g. ModName::DirectiveClassDoc to contain
> supporting doc specifications?
>
> Similar to scheme for packaging and locating test cases - my_directive.rb
> + my_directive.rb pair of files.
>
> Also include optional attribute_name in there, so that our implementation
> of the standard class method attr_name on DirectiveBase can check for
> override before dropping into default_attr_name backstop. (Or maybe that
> just all migrates into DirectiveInfo as method #attr_name or
> #attribute_name; I prefer the longer form, actually)
>
> I'd also like a namespace attribute in there to provide the foundation for
> supporting multiple namespaces: #namespace_name. That would then be
> exploited by our standard methods for forming fully-qualified attribute
> names. Someone assembling a library of addons could then subclass
> DirectiveInfo to install their own std namespace value and then use
> MyCustomDirectiveLibraryDirectiveIinfo in their directives.
>
> So directive protocol proposal: #directive_name returns the
> fully-qualified name of the directive's attribute; #attribute_name returns
> the simple attribute name, #namespace_name returns the namespace prefix
> qualifier. Maybe deprecate the original #full_attr_name currently in
> DirectiveBase, would like to use method names that directly reflect XML
> namespace terminology for qnames.
>
> Believe we'll also also need an override mechanism for namespaces in the
> MV config options, just as xmlns markup allows the usage site to override
> the creator's namespace in order to resolve namespace collisions in their
> documents, but that would build on top of the basic facility.
>
> ~ Deb
>
> ------------------------------
> *From:* Jeff Barczewski [mailto:jeff.barczewski at gmail.com]
> *Sent:* Monday, July 17, 2006 7:12 AM
> *To:* masterview-devel at rubyforge.org; djlewis at acm.org
> *Subject:* Another idea for the single file format for directives
>
> We could use an inner class to hold the description and examples
>
> class MyDirective
> class MetaInfo
> def description
> ...
> end
>
> def example
> ...
> end
>
> end
> end
>
> or even simply a Map to hold the pieces.
>
> Just other ideas to add to the list.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060718/05c6c330/attachment.html
From djlewis at acm.org Tue Jul 18 16:49:47 2006
From: djlewis at acm.org (Deb Lewis)
Date: Tue, 18 Jul 2006 13:49:47 -0700
Subject: [Masterview-devel] Another idea for the single file format for
directives
In-Reply-To: <19cda190607181234s78558198ld294ddf1d7eb2180@mail.gmail.com>
Message-ID: <20060718204951.XYRN27857.fed1rmmtao08.cox.net@DLI92cx797990>
Jeff - sounds like this is converging. I think 2 files, one for the
directive impl that's dropped into directives load path and one for unit
tests, are needed. Not good to introduce dependency on test environment in
the directive file itself, you want to be able to deploy app with just the
production code base.
If you're competent enough to write a unit test (!), you can certainly cope
with uploading two files rather than 1.
So - nitty detail: one MetaInfo class or 2, to separate doc/examples from
the runtime specification. Maybe that's just going overboard and 1 is fine,
I waffle on how zealous to be on separating possible layers of code for that
sort of thing.
Whether to embed (include) the MI class or to have it as sibling class
located by convention based on directive class name maybe depends on whether
embedding will have the right characteristics if we bolt a degenerate guy
into DirectiveBase, I think. Not sure we should put something in
DirectiveBase that pins down namespace_name='mv', because that's only
appropriate for our builtin guys, but not necesssarily custom directives.
or maybe this is a place for a magic convenience decl notation implemented
in DirectiveBase that provides simple declarative notation for attr/ns name
and description:
directive :attribute=>'coolthing', :namespace => 'myguys', :description
=> 'One line summary of my cool thingy'
.. something like that (my coding fingers are bit confused today hopping
between ruby, python, and smalltalk, ack).
And need to recheck the DirectoryRegistry loading magic to make sure it'd do
the right thing if a file on the directives path has more than one class in
it (think it does, just don't have that code up right this instant)
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060718/f3c22ffe/attachment-0001.html
From jeff.barczewski at gmail.com Tue Jul 18 17:59:34 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Tue, 18 Jul 2006 16:59:34 -0500
Subject: [Masterview-devel] Another idea for the single file format for
directives
In-Reply-To: <20060718204951.XYRN27857.fed1rmmtao08.cox.net@DLI92cx797990>
References: <19cda190607181234s78558198ld294ddf1d7eb2180@mail.gmail.com>
<20060718204951.XYRN27857.fed1rmmtao08.cox.net@DLI92cx797990>
Message-ID: <19cda190607181459w22a77d62yfadc8213d6cba0d8@mail.gmail.com>
Yes, the plugin loading registry thing simply require's the files in the
directory so it will load all the classes in there, not a problem there. By
having subclassed DirectiveBase we get informed of the directives as they
are defined no matter where they got required from or how (file, gem, etc).
So all the other meta classes would get parsed but since they don't subclass
DirectiveBase they don't show up as loaded directives but can certainly be
utilized. We could have a MetaInfoBase that they subclass if we wanted to
get all the directives that provide meta info using same mechanism.
If we used a DSL we could hide many of the complexities like you were
suggesting.
I think it is coming along here.
On 7/18/06, Deb Lewis wrote:
>
> Jeff - sounds like this is converging. I think 2 files, one for the
> directive impl that's dropped into directives load path and one for unit
> tests, are needed. Not good to introduce dependency on test environment in
> the directive file itself, you want to be able to deploy app with just the
> production code base.
>
> If you're competent enough to write a unit test (!), you can certainly
> cope with uploading two files rather than 1.
>
> So - nitty detail: one MetaInfo class or 2, to separate doc/examples from
> the runtime specification. Maybe that's just going overboard and 1 is fine,
> I waffle on how zealous to be on separating possible layers of code for that
> sort of thing.
>
> Whether to embed (include) the MI class or to have it as sibling
> class located by convention based on directive class name maybe depends on
> whether embedding will have the right characteristics if we bolt a
> degenerate guy into DirectiveBase, I think. Not sure we should put
> something in DirectiveBase that pins down namespace_name='mv', because
> that's only appropriate for our builtin guys, but not necesssarily custom
> directives.
>
> or maybe this is a place for a magic convenience decl notation implemented
> in DirectiveBase that provides simple declarative notation for attr/ns name
> and description:
>
> directive :attribute=>'coolthing', :namespace => 'myguys', :description
> => 'One line summary of my cool thingy'
>
> .. something like that (my coding fingers are bit confused today hopping
> between ruby, python, and smalltalk, ack).
>
> And need to recheck the DirectoryRegistry loading magic to make sure it'd
> do the right thing if a file on the directives path has more than one class
> in it (think it does, just don't have that code up right this instant)
>
> ~ Deb
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060718/51f4ec23/attachment.html
From jeff.barczewski at gmail.com Mon Jul 24 08:38:51 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 24 Jul 2006 07:38:51 -0500
Subject: [Masterview-devel] Masterview issues
In-Reply-To: <2B69F2107F60A941B935F4B4144191AE1A061C@calfee.ExpressoFitness.com>
References: <2B69F2107F60A941B935F4B4144191AE1A061C@calfee.ExpressoFitness.com>
Message-ID: <19cda190607240538w104c6a14o83645a9d42add799@mail.gmail.com>
Ian,
Thanks for the feedback. Sorry for not getting back sooner, I was on
vacation. Everything you are doing looks correct. I develop on linux
(gentoo) as well so it shouldn't be an issue with the OS.
Are you running through Webrick, Mongrel, Lighttpd, or Apache?
It looks like maybe you are running through Lightty or Apache. I would be
curious to see if the pages worked if you forced webrick. That would tell me
that we simply need to focus on the apache or lighttpd configuration.
You would test this by doing
script/server webrick
http://localhost:3000/customers
If this works then let me know whether you are using lighttpd or apache and
I can focus on testing with that.
I have tested with webrick, mongrel, and lighttpd, but not apache yet, so
maybe I have an issue to iron out there.
In your startup logs whether that is in the logs directory or elsewhere you
should see
INFO MasterView: Adding hook to allow MasterView to check for templates
that have changed when processing a request
INFO MasterView: Adding hooks to enable Rails to read erb directly from
MasterView
INFO MasterView: MasterView plugin initialized - Version 0.2.3
I would be curious to know if these messages are showing up when running in
both webrick mode and against apache/lighttpd
If we aren't seeing these logs, then the masterview plugin is not being
loaded for some reason in that environment.
In the meantime I will do some testing with apache to see if I can find any
problems running with it.
Let me know what you find out from the suggestions above and then it will
help me know where to focus.
Blessings,
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060724/cde23678/attachment.html
From jeff.barczewski at gmail.com Mon Jul 24 19:19:35 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 24 Jul 2006 18:19:35 -0500
Subject: [Masterview-devel] Masterview issues
In-Reply-To: <19cda190607240538w104c6a14o83645a9d42add799@mail.gmail.com>
References: <2B69F2107F60A941B935F4B4144191AE1A061C@calfee.ExpressoFitness.com>
<19cda190607240538w104c6a14o83645a9d42add799@mail.gmail.com>
Message-ID: <19cda190607241619m5e68cb68ke2eff9135e187126@mail.gmail.com>
Ian,
There definitely is a bug in that when running from apache scgi MasterView
was not being loaded. I have made a fix and am testing it. I should be able
to release the new gem tomorrow.
Blessings,
Jeff
On 7/24/06, Jeff Barczewski wrote:
>
> Ian,
>
> Thanks for the feedback. Sorry for not getting back sooner, I was on
> vacation. Everything you are doing looks correct. I develop on linux
> (gentoo) as well so it shouldn't be an issue with the OS.
>
> Are you running through Webrick, Mongrel, Lighttpd, or Apache?
>
> It looks like maybe you are running through Lightty or Apache. I would be
> curious to see if the pages worked if you forced webrick. That would tell me
> that we simply need to focus on the apache or lighttpd configuration.
> You would test this by doing
>
> script/server webrick
> http://localhost:3000/customers
>
> If this works then let me know whether you are using lighttpd or apache
> and I can focus on testing with that.
>
> I have tested with webrick, mongrel, and lighttpd, but not apache yet, so
> maybe I have an issue to iron out there.
>
> In your startup logs whether that is in the logs directory or elsewhere
> you should see
>
> INFO MasterView: Adding hook to allow MasterView to check for templates
> that have changed when processing a request
> INFO MasterView: Adding hooks to enable Rails to read erb directly from
> MasterView
> INFO MasterView: MasterView plugin initialized - Version 0.2.3
>
> I would be curious to know if these messages are showing up when running
> in both webrick mode and against apache/lighttpd
>
> If we aren't seeing these logs, then the masterview plugin is not being
> loaded for some reason in that environment.
>
> In the meantime I will do some testing with apache to see if I can find
> any problems running with it.
>
> Let me know what you find out from the suggestions above and then it will
> help me know where to focus.
>
> Blessings,
>
> Jeff
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060724/bd1787e6/attachment.html
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-devel] [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-devel/attachments/20060726/9a98fa77/attachment.html
From jeff.barczewski at gmail.com Fri Jul 28 11:16:11 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Fri, 28 Jul 2006 10:16:11 -0500
Subject: [Masterview-devel] Some rough ideas for ajax grid table directive
syntax
Message-ID: <19cda190607280816r607becadj91c52b661ba659e1@mail.gmail.com>
Deb,
I have been planning for a directive that would add ajax capabilities to an
ordinary table (ajax sort, page forward/back), this would make it dead
simple to add this functionality without doing any manual javascript work.
The idea is to make this very easy to add to an existing table. Additional
things could be done to do inline edit and stuff like that, but I will save
that for later.
Here is an idea for the syntax
It basically identifies what model we are pulling from, what columns, what
the sort and secondary sort would be for each column (when you click on the
heading to sort). It would generate the proper rhtml and partials under the
covers and all the necessary javascript to click on headings etc. If you
don't care about secondary sort then you can even eliminate the :sort param.
Name
Description
Date
name1
desc1
date1
or alternately specifying the columns using nested directives so that they
could be rearranged in WYSIWYG editor. Directives can work with nested
directives to accomplish interesting things or for that matter they can also
read style or anything that is nested.
Name
Description
Date
name1
desc1
12/31/2006
and if we go the extra step to allow alternating row styles we could allow
this, the below would apply rowStyle1, rowStyle2, and rowStyle3 to each row
allowing a nice striping effect
Name
Description
name1
desc1
name2
desc2
name3
desc3
name4
desc4
name5
desc5
name6
desc6
Let me know what you think. But these are the types of directives that I
think really show off the power of MasterView.
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060728/290d08d3/attachment-0001.html
From jeff.barczewski at gmail.com Sat Jul 29 15:08:08 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Sat, 29 Jul 2006 14:08:08 -0500
Subject: [Masterview-devel] I added the default generate feature
Message-ID: <19cda190607291208k4024a905k4661b1e4db1969fc@mail.gmail.com>
I added the default generate feature we discussed prior. If you don't have
any mv:generate or mv:gen_partials in your template then it will add a
mv:generate="{template_path}" to either your body (if found) or the root
element. If it adds to the body then it also adds in a mv:omit_tag="" as
well.
I implemented this as a filter which uses a regex scan, so this made it
simple to tack on.
Since it is a filter it is configured using config.default_parser_options
I named the option for this filter :default_generate with a default value of
true, however if you think a different name would be clearer I am all ears.
I also noted that in our configuration if a user sets the hash absolutely
like
config.default_parser_options = { :tidy => true }
then they have effectively set tidy true, but also set all the others to
false including new ones that we would might add in the future. Since I
think we would rather just force users to set them to false when they want
them disabled and also allow us to pick up future options as they are
available, I changed the configuration slightly to take the users
default_parser_options and to merge them with the original set. This gives
us the desired effect in that future options are picked up by default, and
users can still disable by setting an option to false or nil.
I enabled the default_generate option in the interactive view as well so
that when they are testing things they can try out things easily.
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060729/756fd6f5/attachment.html
From djlewis at acm.org Sun Jul 30 13:09:21 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sun, 30 Jul 2006 10:09:21 -0700
Subject: [Masterview-devel] I added the default generate feature
In-Reply-To: <19cda190607291208k4024a905k4661b1e4db1969fc@mail.gmail.com>
Message-ID: <20060730170926.OWXY6711.fed1rmmtao04.cox.net@DLI92cx797990>
>> I added the default generate feature
Good, had been thinking further about that last week while at OSCON and I
think it's a good default behavior. Makes it easy to bring existing content
pages into your rails app; just get the pages in and working, then you can
decide whether/how to start exploiting rails markup or revising the page to
fit into the site layout. Might be mainly a transition strategy feature,
but useful nonethless. Haven't thought of a downside yet and if so the
feature can always be disabled.
Still contemplating whether parser options is the right place for that
setting, though; I think it may be more appropriate as a config setting
related to an input directory area. I'm thinking through a case where I may
want to be able to pull in content pages to map into a view section that
aren't physically stored under app/views; that would also require revisiting
our deferred item on being able to configure multiple i/o trees. I'll play
with that this week, it ties into the area of my site that I'm trying to get
reworked and published under rails.
RE: rework in how Config handles parser options to protect against user
bashing the original hash and losing some of our settings
Good spot, I wasn't real happy with that area but hadn't put much thought
into cleaning it up. I actually think I'd like to go back into that one
more time and revise it to disallow direct access to the hash. Maybe better
to have explicit get/set parser option protocol and not allow clients to
(inadvertantly) bash the options hash in the first place.
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060730/6c16d11f/attachment.html
From djlewis at acm.org Sun Jul 30 14:31:31 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sun, 30 Jul 2006 11:31:31 -0700
Subject: [Masterview-devel] Why your logging in
Initializer#initialize_configuration didn't work
Message-ID: <20060730183135.XMLW1537.fed1rmmtao07.cox.net@DLI92cx797990>
initializer.rb method initialize_configuration(lines 715-715):
# this logging didn't seem to work??
# @log_msg_q << [ :info, 'Program name = '+$PROGRAM_NAME ] # log the
program that is starting
That didn't work because there's still some excessively tricky
back-and-forth between how the initalizer gets run in the normal scenario
when app [rails plugin] startup loads masterview.rb and a backstop for
non-standard init scenarios in which the initializer gets run explicitly.
(and reporting bad directive_path entries, the original reason I invented
that @log_msg_q gadget, also didn't work; ain't testing a grand idea)
Fixed by reworking the way early-init messages are recorded and installing
the logger a bit earlier in the init process (do right after MV itself is
loaded, before the MIO init or any other startup processing)
~ Deb
From jeff.barczewski at gmail.com Sun Jul 30 23:22:09 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Sun, 30 Jul 2006 22:22:09 -0500
Subject: [Masterview-devel] Why your logging in
Initializer#initialize_configuration didn't work
In-Reply-To: <20060730183135.XMLW1537.fed1rmmtao07.cox.net@DLI92cx797990>
References: <20060730183135.XMLW1537.fed1rmmtao07.cox.net@DLI92cx797990>
Message-ID: <19cda190607302022n599da29dy96e971d43211a0a3@mail.gmail.com>
great! I was thinking of logging the program name so that it would be easy
to fix a problem if masterview was not being loaded if brought up in a new
environment (not webrick, lighttpd, fcgi, scgi). The way things work we
need to know the program name. However if possible I would like to find a
better way that looks for something defined and not just the program name. I
haven't been able to find the right thing yet. So for the apache scgi patch
I just added more to the program name match.
On 7/30/06, Deb Lewis wrote:
>
> initializer.rb method initialize_configuration(lines 715-715):
>
> # this logging didn't seem to work??
> # @log_msg_q << [ :info, 'Program name = '+$PROGRAM_NAME ] # log the
> program that is starting
>
> That didn't work because there's still some excessively tricky
> back-and-forth between how the initalizer gets run in the normal scenario
> when app [rails plugin] startup loads masterview.rb and a backstop for
> non-standard init scenarios in which the initializer gets run explicitly.
>
> (and reporting bad directive_path entries, the original reason I invented
> that @log_msg_q gadget, also didn't work; ain't testing a grand idea)
>
> Fixed by reworking the way early-init messages are recorded and installing
> the logger a bit earlier in the init process (do right after MV itself is
> loaded, before the MIO init or any other startup processing)
>
> ~ 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/20060730/b75230dc/attachment.html
From jeff.barczewski at gmail.com Sun Jul 30 23:34:42 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Sun, 30 Jul 2006 22:34:42 -0500
Subject: [Masterview-devel] Revised and simplified directive base
Message-ID: <19cda190607302034v6880e21em908ac7f4204588a4@mail.gmail.com>
Deb,
After looking further at a DSL or simplification of our directive api,
I realized that I could make things pretty easy with a couple key
methods. So the resultant code would look something like this
def etag(dcs)
arg :obj, :quote => true
arg :method, :quote => true
arg :options, :merge => [:common_html, :size, :maxlength]
erb_content 'text_field', :obj, :method, :options
end
I have most of the details and necessary code for this, just working
through a few more minor issues and how we can cleanup.
This should really simply most of our directives to a handful of lines
of code which feels like a DSL.
I still have the other features I mentioned before as well. I will
provide some more complete examples soon.
This is feeling pretty good and it came together nicely. I think it
really makes things pretty easy. Much of the complexity is all hidden
from the user and unlike the previous api, it's much harder to mess up
:-)
Jeff
From djlewis at acm.org Sun Jul 30 23:55:53 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sun, 30 Jul 2006 20:55:53 -0700
Subject: [Masterview-devel] Some rough ideas for ajax grid table
directive syntax
In-Reply-To: <19cda190607280816r607becadj91c52b661ba659e1@mail.gmail.com>
Message-ID: <20060731035609.THYB6303.fed1rmmtao09.cox.net@DLI92cx797990>
Jeff - got it, need to "digest" a bit before responding. Tables always end
up being ridiculously complicated because of the endless little variations
and complexities, so the challenge is to do something that's simple but not
useless.
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060730/e518745c/attachment.html
From jeff.barczewski at gmail.com Mon Jul 31 14:31:18 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 31 Jul 2006 13:31:18 -0500
Subject: [Masterview-devel] Some rough ideas for ajax grid table
directive syntax
In-Reply-To: <20060731035609.THYB6303.fed1rmmtao09.cox.net@DLI92cx797990>
References: <19cda190607280816r607becadj91c52b661ba659e1@mail.gmail.com>
<20060731035609.THYB6303.fed1rmmtao09.cox.net@DLI92cx797990>
Message-ID: <19cda190607311131l44d7a628xdfbbee015d8b2862@mail.gmail.com>
Right, One needs to find the 80% solution that meets a good portion of
users needs. However I think one can take something simple and if one
takes into account nested directives one can get a good portion of
that other 20% too. For instance if the default ajax_grid directive by
default simply outputs the data for each field in the td columns, one
could always apply a mv:content directive to override this and fill it
with whatever is wanted.
I think similar to Streamlined you can get most of the way there if
you have some simple config options, but then if you combine other
directives into the mix we can pretty much do anything.
One would always have the ability to code up partials as we do today
and then drive them however they want, but I think for many situations
we can just make this easier.
Jeff
On 7/30/06, Deb Lewis wrote:
>
>
> Jeff - got it, need to "digest" a bit before responding. Tables always end
> up being ridiculously complicated because of the endless little variations
> and complexities, so the challenge is to do something that's simple but not
> useless.
>
> ~ Deb
From jeff.barczewski at gmail.com Mon Jul 31 14:36:28 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 31 Jul 2006 13:36:28 -0500
Subject: [Masterview-devel] Some rough ideas for ajax grid table
directive syntax
In-Reply-To: <19cda190607311131l44d7a628xdfbbee015d8b2862@mail.gmail.com>
References: <19cda190607280816r607becadj91c52b661ba659e1@mail.gmail.com>
<20060731035609.THYB6303.fed1rmmtao09.cox.net@DLI92cx797990>
<19cda190607311131l44d7a628xdfbbee015d8b2862@mail.gmail.com>
Message-ID: <19cda190607311136m25f2e5ees58334b43a6cbec38@mail.gmail.com>
Also just to note, after I thought about it more, I think that the
first syntax where the majority of the info is specified in the
directive is the most straight forward. We can still pick up the
distinct row styles if there is to be alternating row format along
with the other style specifics for the particular columns. We'd use
the first td row for the partial to iterate on, injecting the
appropriate row style based on the mod count.
Jeff
On 7/31/06, Jeff Barczewski wrote:
> Right, One needs to find the 80% solution that meets a good portion of
> users needs. However I think one can take something simple and if one
> takes into account nested directives one can get a good portion of
> that other 20% too. For instance if the default ajax_grid directive by
> default simply outputs the data for each field in the td columns, one
> could always apply a mv:content directive to override this and fill it
> with whatever is wanted.
>
> I think similar to Streamlined you can get most of the way there if
> you have some simple config options, but then if you combine other
> directives into the mix we can pretty much do anything.
>
> One would always have the ability to code up partials as we do today
> and then drive them however they want, but I think for many situations
> we can just make this easier.
>
> Jeff
>
> On 7/30/06, Deb Lewis wrote:
> >
> >
> > Jeff - got it, need to "digest" a bit before responding. Tables always end
> > up being ridiculously complicated because of the endless little variations
> > and complexities, so the challenge is to do something that's simple but not
> > useless.
> >
> > ~ Deb
>
From jeff.barczewski at gmail.com Mon Jul 31 17:02:29 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 31 Jul 2006 16:02:29 -0500
Subject: [Masterview-devel] Revised and simplified directive base -
would like your input on syntax and approach as soon as possible
Message-ID: <19cda190607311402r4e82925fq95794b789f0dc92e@mail.gmail.com>
To implement this DSL I created some powerful methods
arg(instance_var_name, options) - gets a subargument out of the
attr_value, shifting that subarg off the array so that subsequent
calls will get the next subarg. Peform quoting or merging with html
attributes. Define optional_default which will be used if the value is
empty but needed when building a method call and post params are
non-null. Stores this to an instance_var_name.
erb_content and erb_eval can now take a string and a *args and it
contains all the logic to build up the appropriate erb calls.
I also added a method render which can be used to easily allow the
developer to package up multiple outputs from a method. So rather than
building up an array themselves and returning it, they can simply call
render as many times as necessary and it will return the complete
collection of outputs. The only gotcha is that it needs to be called
as the last method in the event (so that the results are returned from
the event). (This avoided us having to go to a more complicated block
dsl which I think has its own issues, but is this too risky or can it
be handled with simple documentation and examples).
For completeness I added a method called render_nothing which returns
nil, this is used when for the events that don't want to render
anything.
I added a method called continue which calls the dcs.render which
allows continuation of rendering down the directive call stack. So if
you want to do this and to output it then you can do 'render
continue' or of course set the results to a variable and manipulate.
The resulting syntax looks like this
def etag(dcs)
arg :obj, :quote => true
arg :method, :quote => true
arg :foo, { 'override with this value'}
arg :bar, { |x| x.downcase } # lowercasing the arg before setting it to @bar
arg :options, :merge => [:common_html, :size, :maxlength]
render erb_content 'text_field', :obj, :method, :options
render continue
render erb_eval 'end'
end
To access the full directive attribute value use attr_value
To access or set element attributes, use attr[:class] or attr['class']
To access content of element, use content to get array, or content_str
to get joined version
How does this look to you? It really cleans things up considerably
from the old code and should be much more foolproof to user not
understanding the complexities.
Are my naming conventions ok? (arg, render, continue, :quote, :merge,
:optional_default)
Once this is in place I would like to get rid of the old cludgy
methods that are no longer needed in directive_base and
directive_helpers. However what is the best approach to doing this?
Do I make these methods in a new base class SimplifiedDirectiveBase?
Does it inherit from DirectiveBase? or do I add them directly to
DirectiveBase? Do I try to remove the methods that I don't want in
there after making sure nothing in our system or any submitted
directives are using? Not sure the best approach to cleaning this up.
I don't want to leave around all those redundant methods which are not
fully debugged and are tricky to use properly. I want to have a clean
minimal set of methods that make it clear how to operate. Obviously we
will document whatever we do and increment version when we make such
an api jump.
Need your input on this as soon as you get a chance since I am just
about ready to rewrite the directives using the new api once you
confirm the naming and the upgrade approach. Or if you think that we
really need to move towards a block dsl (to get around the need for
render to be last call in method) then I'll have to work on that
(using these method calls to get us most of the way there was really
easy).
Thanks,
Jeff