On Aug 28, 11:20 pm, Timothy Perrett <timo...@getintheloop.eu> wrote:
> Hey Marius
>
> Firstly I agree with your thoughts on LiftTagPF - im not sure that
> overriding the default lift tags would ever be a good idea for
> implementing users...
Well I was referring to overwriting (as those would take precedence
over builtin snippets) ... not much of an overriding.
> However, I do see a use case, in, for instance
> the CMS arena where having a specialized tagging mechanism would be
> beneficial because you simply wouldn't want to use the default lift
> namespace so that users could just do:
>
> <lift:comet type="Whatever" />
>
> All over their template code - you'd want to restrict what users could
> actually do whilst still keeping the templates designer friendly.
Such restrictions could be very tricky to achieve if the CMS template
is processed by Lift engine. Perhaps for specialized CMS templates a
dedicated templating definition and engine is more appropriate in
order to strictly process given tags that define the CMS templating
language?
>
> This is one use case, and in my particular circumstances, I want to
> provide a degree of functionality that is succinctly separate from the
> lift functionality and I don't want the twain to meet (as it were) but
> its important for my purposes at least that the templates still play
> well with tools such as Dreamweaver (just as the lift tags do)
>
> What are your thoughts?
Related to my notes above if you define a set of tags for your CMS
template and you run that against Lift's templating engine how do you
prevent lift specific "tags" to be executed?
>
> Cheers, Tim
>
> On Aug 28, 5:48 pm, "marius d." <marius.dan...@gmail.com> wrote:
>
> > Personally I'm not a fan of such feature. To me this doesn't bring
> > much benefits especially that snippets pretty much allow this support
> > such as:
>
> > <lift:MySnippet>
> > <something:notlift attr="whatever" />
> > </lift:MySnippet>
>
> > ...yes the wrapping tag is extra typing but still I can't find a real
> > problem where a custom tags solves it and snippets do now. To me this
> > looks like ... what I'd call "a false sense of extensibility". I mean
> > at the first glance we allow people to define a tag soup (with or
> > without naming overlaps) but then looking closely is that we didn't
> > actually do too much. Snippets would do the job in a more
> > "standardize" lift way IMO.
>
> > For what I can tell the LiftRules.LiftTagPF should probably be
> > deprecated. The debatable value that I could currently find in
> > LiftTagPF is that people could overwrite Lift built in snippets with
> > some proprietary implementation. However in practice this is not
> > really needed .. I think.
>
> > All in all I'd love to see some types of problems where custom tags
> > would be a better fit.
>
> > Br's,
> > Marius
>
> > On Aug 28, 7:30 pm, Timothy Perrett <timo...@getintheloop.eu> wrote:
>
> > > Hey David,
>
> > > Id like to echo your thoughts - I see no issue with views being tied
> > > to plugins or other such arbitrary tags... as you say, they are
> > > already tied to snippets.
>
> > > What are your thoughts on how arbitrary tag / prefix support could be
> > > implemented?
>
> > > Cheers, Tim
>
> > > > There's been some discussion of this feature in the past. The generally
> > > > outcome is that cost of prefix/label soup would become very confusing
> > > > because the views become tied to plugins (although this seems weird to
> > > > me
> > > > because views are tied to snippets.)
>
> > > > I think in light of the modularization discussion and the potential for
> > > > snippet name overlap, it might be having the discussion about supporting
> > > > arbitrary tags and arbitrary attributes in Lift's templating system.
>
> > > > Anybody have thoughts?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
