I'm a little late to the game, but my vote would be for keeping all
lift-related attrs under the lift prefix. I don't feel like we need to
attach any meaning the the lift prefix other than that it's something that
lift will use.

Derek


On Thu, Oct 1, 2009 at 9:39 PM, marius d. <marius.dan...@gmail.com> wrote:

>
> David,
>
> Thank you very much for your kind words. Personally I don't see any
> reason why the lift prefix can not also have the semantic for
> enriching the context you described  "this thing will be changed based
> on evaluating some code.". These are after all attributes and
> attributes to me are about about meta-data on how lift will change
> markup.
>
> I will do what you suggested hopefully by next Monday ... and this
> time using the proper process ;)
>
> Br's,
> Marius
>
> On Oct 1, 7:03 pm, David Pollak <feeder.of.the.be...@gmail.com> wrote:
> > Marius,
> > I have a ton of respect for your opinion and I appreciate your analysis.
> >
> > I have been following this thread and thinking, "what does the lift:
> prefix
> > mean?"  In my mind, it means "this thing will be changed based on
> evaluating
> > some code."  So, using the lift: prefix for something that also means
> "this
> > modifies the meaning of this snippet invocation" presents
> > something discordant to me.
> >
> > With that being said, I'm going to hand the decision to you.  I trust
> your
> > decisions and have concerns about my own instincts when it comes to
> naming.
> >
> > Please update the code to reflect what you think it should be and merge
> it
> > into master.
> >
> > Thanks,
> >
> > David
> >
> > On Thu, Oct 1, 2009 at 5:58 AM, marius d. <marius.dan...@gmail.com>
> wrote:
> >
> > > Well I said what I had to say. My problem is not really the prefix
> > > name but the existence of other prefixes then lift, that are
> > > interpreted by lift. It's just how I see things now and nothing on
> > > this thread provided sufficient arguments to convince me
> > > otherwise ...
> >
> > > not much else for me to do if majority and especially DPP thinks
> > > otherwise. It is what it is I guess.
> >
> > > Br's,
> > > Marius
> >
> > > On Oct 1, 4:18 am, Naftoli Gugenheim <naftoli...@gmail.com> wrote:
> > > > I think everyone agrees in concept, that an arbitrary prefix sets a
> bad
> > > precendent, which is why it is no longer do:par. But on the other hand,
> if
> > > the part after "lift:" is either a reserved word or a "user" word--a
> snippet
> > > name--then the more reserved words, the more you limit snippet names.
> > > (Should S.mapSnippet("parallel", ...) throw an exception?)
> > > > So we have these two considerations on either end of the spectrum.
> > > Arguably, "liftx" as a prefix satisfies both--it is sufficiently
> generic to
> > > include almost any "special" attribute that may be added, it clearly
> spells
> > > out "extended lift attribute," and on the other hand it keeps reserved
> lift
> > > attributes separate from the user's snippet namespace.
> > > > Now let's bear in mind that this is all only relevant in the future,
> when
> > > lift: attributes indeed will be interpreted as lift:snippet="..." is
> now. At
> > > that point it might make sense for the explicit :snippet format to be
> moved
> > > to the liftx prefix-- liftx:snippet="..." --for the same reason, not to
> > > encroach on the snippet namespace.
> >
> > > > -------------------------------------
> >
> > > > marius d.<marius.dan...@gmail.com> wrote:
> >
> > > > It has been debated many times in slightly different contexts. To me
> > > > it is more about clarity. We add a new prefix now, tomorrow add
> > > > another one and so on. People would have to remember what goes where
> > > > and  mix things up. To me lift prefix is enough and quite clear. It
> is
> > > > more than just s snippet thingy. It tells the user "hey this thing is
> > > > telling the framework something and the framework is doing something
> > > > with it". It is separating framework xml markup from the actual xhtml
> > > > markup. Having a single reserved prefix promotes clarity and keeps
> > > > things simple and rather intuitive.
> >
> > > > I'm not in favor of using unprefixed attributes like
> > > > par="something" (btw I really don't like par naming :) ...) because
> > > > unprefixed attributes should be only standard xhtml ones or the ones
> > > > that user explicitly specifies it. So lift:parallel="true" or
> > > > lift:async="true" should be just fine.
> >
> > > > Br's,
> > > > Marius
> >
> > > > On Sep 30, 8:05 pm, Naftoli Gugenheim <naftoli...@gmail.com> wrote:
> >
> > > > > Could you elaborate on why adding a new prefix may not be a good
> idea?
> > > And is it better or worse than having it unprefixed?
> >
> > > > > -------------------------------------
> >
> > > > > marius d.<marius.dan...@gmail.com> wrote:
> >
> > > > > On Sep 30, 8:23 am, Kevin Wright <kev.lee.wri...@googlemail.com>
> > > > > wrote:
> >
> > > > > > I thought there were issues here because anything starting lift:
> gets
> > > > > > executed as a snippet.
> >
> > > > > Correct BUT lift:par or lift:parallel attributes are also
> applicable
> > > > > to snippets context. They determine the snippet's execution
> semantics.
> > > > > So I'm still questioning the need for a new prefix.
> >
> > > > > > I'm still for an eval: prefix, as these proposals all relate to
> how a
> > > > > > page is evaluated.
> >
> > > > > > On Wed, Sep 30, 2009 at 5:34 AM, marius d. <
> marius.dan...@gmail.com>
> > > wrote:
> >
> > > > > > > lift is already a "reserved" prefix for snippets. So I'd stay
> with
> > > > > > > simply lift prefix for these attributes as well.
> >
> > > > > > > Br's,
> > > > > > > Marius
> >
> > > > > > > On Sep 29, 11:11 pm, Naftoli Gugenheim <naftoli...@gmail.com>
> > > wrote:
> > > > > > >> So what is your proposal? Am I interpreting you correctly that
> you
> > > are for a prefix of 'lift'? And it will be a reserved suffix?
> >
> > > > > > >> -------------------------------------
> >
> > > > > > >> marius d.<marius.dan...@gmail.com> wrote:
> >
> > > > > > >> I realize that I may be a little late here but I do have
> second
> > > > > > >> thoughts about liftx prefix. Yeah, I'm not a big fan of it. I
> > > > > > >> understand that these attributes are not really snippets or
> built
> > > is
> > > > > > >> snippets but is this an enough reason to introduce a new
> prefix?
> > > > > > >> Personally I don't think so. Historically lift reserved prefix
> > > names
> > > > > > >> were heavily debated and argued and this is a little sensitive
> > > area.
> >
> > > > > > >> But the good news is that I may be the only one feeling this
> way
> > > about
> > > > > > >> this and everyone else likes it so I'm just a negligible
> minority.
> >
> > > > > > >> Br's,
> > > > > > >> Marius
> >
> > > > > > >> On Sep 25, 12:02 pm, David Pollak <
> feeder.of.the.be...@gmail.com>
> > > > > > >> wrote:
> >
> > > > > > >> > On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim <
> > > naftoli...@gmail.com>wrote:
> >
> > > > > > >> > > If you like the idea of having them all as attributes but
> > > don't like the
> > > > > > >> > > idea of using a single attribute ('xx:eager_eval="true"
> > > xx:parallel="true"'
> > > > > > >> > > rather than 'xx:eval="eager parallel"' as I suggested,
> where
> > > xx is the
> > > > > > >> > > prefix to be chosen) then maybe the prefix should be
> 'eval'.
> >
> > > > > > >> > I've changed the code to:
> > > > > > >> > liftx:eager_eval="true"
> > > > > > >> > liftx:par="true" | liftx:parallel="true"
> >
> > > > > > >> > The reasons for not combining them:
> >
> > > > > > >> >    - They are evaluated in different parts of the code, thus
> > > eager/parallel
> > > > > > >> >    doesn't make sense from a code path perspective
> > > > > > >> >    - I am reserving the value of liftx:par for future
> > > implementation to
> > > > > > >> >    allow farming the snippet evaluation to another
> mechanism.
> > >  Right now, it's
> > > > > > >> >    hard-coded to use LiftActors.  I can see a time when it
> would
> > > work with Akka
> > > > > > >> >    actors or some other parallelization mechanism
> >
> > > > > > >> > > As far as "ajax evaluation" I'm not sure I'm
> understanding.
> > > Could you show
> > > > > > >> > > me what you're thinking?
> > > > > > >> > > If I have a snippet
> > > > > > >> > > <lift:MySnippet />
> > > > > > >> > > what would be the syntax to have it inserted via ajax?
> >
> > > > > > >> > <lift:Ajax> <!-- the snippet name will not be ajax, but you
> get
> > > the idea -->
> > > > > > >> >   <lift:MySnippet/>
> > > > > > >> > </lift:Ajax>
> >
> > > > > > >> > > -------------------------------------
> > > > > > >> > > Ross Mellgren<dri...@gmail.com> wrote:
> >
> > > > > > >> > > My 2 cents,
> >
> > > > > > >> > > I'm not sure I'm a fan of do: namespace, though I agree it
> > > would be
> > > > > > >> > > nice to have a common one. Maybe snippet:parallel,
> > > snippet:eager_eval?
> >
> > > > > > >> > > -Ross
> >
> > > > > > >> > > On Sep 24, 2009, at 12:46 PM, David Pollak wrote:
> >
> > > > > > >> > > > On Wed, Sep 23, 2009 at 11:43 AM, Naftoli Gugenheim <
> > > > > > >> > > naftoli...@gmail.com
> > > > > > >> > > > > wrote:
> >
> > > > > > >> > > > What do you mean by "as a normal snippet"?
> >
> > > > > > >> > > > The parallel snippet processing is implemented deep
> inside
> > > > > > >> > > > LiftSession.  It's not a snippet.  All the <lift:xxx/>
> tags,
> > > even
> > > > > > >> > > > those with defaults built into Lift, are implemented as
> > > snippets and
> > > > > > >> > > > are invoked with normal snippet invocation mechanisms.
> >
> > > > > > >> > > > That you will nest your snippet inside a special
> snippet?
> >
> > > > > > >> > > > There is no special snippet.  I used the word "normal"
> to
> > > highlight
> > > > > > >> > > > that it's functionality that doesn't require a change to
> > > LiftSession
> > > > > > >> > > > or other parts of Lift to function correctly.
> >
> > > > > > >> > > > To me it seems worthwhile to have a consistency between
> the
> > > two
> > > > > > >> > > > syntax-wise, since they have some common denominator
> > > semantics-wise.
> > > > > > >> > > > Actually, maybe throw in eager_eval to the mix. Maybe we
> > > could have
> > > > > > >> > > > one eval or lift:eval or liftx:eval or whatever
> attribute,
> > > which can
> > > > > > >> > > > contain a space separated list of specifiers--eager,
> ajax,
> > > parellel.
> >
> > > > > > >> > > > Anything that's prefixed with lift: is a snippet.  I'm
> open
> > > to
> > > > > > >> > > > unifying eager_eval and do:lazy (or do:par or
> do:parallel)
> > > into a
> > > > > > >> > > > unified namespace.
> >
> > > > > > >> > > > -------------------------------------
> > > > > > >> > > > David Pollak<feeder.of.the.be...@gmail.com> wrote:
> >
> > > > > > >> > > > On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim <
> > > > > > >> > > naftoli...@gmail.com
> > > > > > >> > > > >wrote:
> >
> > > > > > >> > > > > A snippet attribute can be invoked with something
> other
> > > than
> > > > > > >> > > > > lift:snippet="Class.method"? There's a short syntax?
> What
> > > is it?
> >
> > > > > > >> > > > There may be a short syntax (e.g., lift:Class.method) in
> the
> > > future.
> >
> > > > > > >> > > > > What was used for the feature that inserts a snippet
> > > > > > >> > > > asynchronously via
> > > > > > >> > > > > Ajax?
> >
> > > > > > >> > > > That feature isn't done yet, but that
> >
> > ...
> >
> > read more ยป
> >
>

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to