$foo/bar{:baz => 'quux'}
The word "Component" is very overused and the definition is quite
ambiguous. I definitely should not have used it. What I think you're
thinking is more like JSF's component model which I find to be quite
atrocious and far from elegant. I was thinking of something a little
closer to Grails' taglibs (http://grails.org/Dynamic+Tag+Libraries)
but anyways, it was just an idea...one that I still think is a good
one, but I'm young and inexperienced. I'll write some code and
experiment and perhaps post back.
On Oct 23, 3:30 pm, "Chris Eppstein" <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 23, 2008 at 12:32 PM, Lex <[EMAIL PROTECTED]> wrote:
>
> > The primary advantage isn't syntactic. How I see it is that a designer
> > who knows HAML, but not Ruby could create components out of partials
> > without having to write any Ruby code.
>
> If your designers are writing your reusable components, you've got bigger
> problems than a lack of tool support. The component frameworks you've
> mentioned are not accessible to designers, they are meant to be written by
> developers and used by designers. Which we've already established is plenty
> easy to do with helpers.
> I'm a big fan of components and I've even done extensive work on
> one:http://github.com/chriseppstein/cells/tree/master
>
> I highly encourage you to explore your options provided by your app
> framework; they are numerous.
>
> > It also adds functionality when
> > using HAML apart from Rails w/o having to roll your own helpers
> > framework. This would help to further decouple HAML from Rails and
> > encourage its use in other environments.
>
> See StaticMatic.
>
> > There is also a clear
> > syntactic advantage over:
>
> > = render :partial => 'foo'
>
> > which would become
>
> > $foo
>
> And what would render :partial => 'foo/bar' become? If you want a component
> named foo you need only write:
>
> def foo(options= {})
> render :partial => "foo", :locals => options
> end
>
> I dare say a designer can even be trained to copy and paste that and change
> the relevant bits. It's certainly no more complicated than any of the
> component registration mechanisms I've seen from the java world.
>
> I'm adding another -1 bringing the grand total to -2.
>
> chris
>
> On Oct 23, 12:14 pm, "Chris Eppstein" <[EMAIL PROTECTED]> wrote:
>
> > > -1 There's no syntactic advantage here over helpers.
> > > = calendar(:month => 'January')
>
> > > = datagrid(:data => @my_hash, :sort_by => 'date', :order => 'asc')
>
> > > -chris
>
> > > On Thu, Oct 23, 2008 at 8:05 AM, Lex <[EMAIL PROTECTED]> wrote:
>
> > > > First off, I just wanted to say Kudos to Hampton Catlin (and everyone
> > > > else involved) for creating HAML, it's the first templating language
> > > > that I've actually liked. Super easy to learn too, I'm in looove!
>
> > > > BUT...
>
> > > > I think it could be made better...How about this:
>
> > > > $component{ :localvar => @vartobind }
>
> > > > Some J**a-based templating systems use this idea (groovy/gsp, and jsf/
> > > > facelets/jsp) to compose templates out of partials, though they use
> > > > the xml namespacing method (i.e. <taglib:tag attr="value" />)
>
> > > > I think this is a great way to make templates more DRY, it allows
> > > > partials to be extracted, reused, and distributed as components, and
> > > > it discourages use of inline code in a template. A backing class could
> > > > be attached to a partial to aid in complex logic.
>
> > > > Some ideas:
>
> > > > $calendar{ :month => 'January' }
>
> > > > $datagrid{ :data => @my_hash, :sort_by => 'date', :order => 'asc' }
>
> > > > What do you all think?
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Haml" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/haml?hl=en
-~----------~----~----~----~------~----~------~--~---
