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 feature is likely to
> be done
> > > > >> > > > as a
> > > > >> > > > normal snippet.
> >
> > > > >> > > > > My concern is that as more features are thought up and
> added they
> > > > >> > > > shouldn't
> > > > >> > > > > all end up with different prefixes.
> > > > >> > > > > Also, if the prefix is nothing special I would go with the
> more
> > > > >> > > > verbose
> > > > >> > > > > "parallel" because otherwise it's not obvious what it
> does. If
> > > > >> > > > it's prefixed
> > > > >> > > > > with "lift:" at least you know it's a lift tag and you can
> look it
> > > > >> > > > up
> > > > >> > > > > somewhere or ask on the list etc. But if you come back to
> some old
> > > > >> > > > template
> > > > >> > > > > that says "do:par" you may be left clueless.
> >
> > > > >> > > > > -------------------------------------
> > > > >> > > > > David Pollak<feeder.of.the.be...@gmail.com> wrote:
> >
> > > > >> > > > > On Wed, Sep 23, 2009 at 3:59 AM, Naftoli Gugenheim <
> > > > >> > > naftoli...@gmail.com
> > > > >> > > > > >wrote:
> >
> > > > >> > > > > > Could that be changed to lift:concurrent or lift:par
> etc. (see
> > > > >> > > > email on
> > > > >> > > > > > scala-user from Marting Odersky mentioned the future use
> of
> > > > >> > > > 'seq' and
> > > > >> > > > > 'par'
> > > > >> > > > > > in concurrent collections)?
> > > > >> > > > > > Why use a different prefix than everything else built in
> to
> > > > >> > > > lift? And
> > > > >> > > > > > 'lazy' is arguably not what's happening.
> >
> > > > >> > > > > We're using a different prefix because if we use a
> lift:xxx
> > > > >> > > > prefix, the
> > > > >> > > > > snippet execution machinery will be invoked on the
> attribute and
> > > > >> > > > we don't
> > > > >> > > > > want that.
> >
> > > > >> > > > > I'm cool with do:par unless anyone has a better
> suggestion.
> >
> > > > >> > > > > Thanks,
> >
> > > > >> > > > > David
> >
> > > > >> > > > > > Thanks.
> >
> > > > >> > > > > > -------------------------------------
> > > > >> > > > > > Jeppe Nejsum Madsen<je...@ingolfs.dk>
> >
> > ...
> >
> > read more ยป
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

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