Parameter Misnomers

&display and &limit seem to fit best, IMO.

It took some reading through the docs to understand how to limit (via summarize in 2.0), but I was able to get it working wonderfully!

I think if &limit is to become &queryLimit (which does make sense indeed), better not to use it or else not only do you risk confusing users but how do you handle backward compatibility ?

I kind of agree that &display is pretty straightforward and more meaningful.
&get and &return just sound too php-ish to me

lol

Words are quite important. My take is, let’s stick to what’s not ambiguous.
Don’t under estimate that Ditto 2.0 brings lots of new things to learn (the price of power), let’s not make that harder yet

&display is probably the best compromise.
I understand that some people could confuse them with pagination parameter at first, but not sure it would stick long : if anything pagination parameters are very well named you can’t really confuse them

Ok, display it is. Change made in SVN: [CHANGED] &show (which was &summarize) to &display

On the same note, should &parents be something like &containers given the fact that we’ve dropped the folder nomenclature?

Good point Mark.

One thing I noticed is, aside from well informed advanced users, a wide portion of people never quite got that the folder nomenclature has been dropped. One reason is : MODx Light theme has no more folder icons but MODx theme still have the yellow folder icons, and some people have stuck with the adaptation from the old MODx theme.


Anyway, it’s true that &containers is more accurate.
Just one remark, since we’re talking ammending parameters : if you go ahead with the changes, better batch them all in one time to avoid to much confusion...

Actually, I just realized that we still have "Document parent" all over the manager so until that is changed, switching &parents to &containers doesn’t make sense.

I agree about not switching from &parents... because that’s entirely accurate as well.

Quote from: Mark at Mar 16, 2007, 03:06 AM

On the same note, should &parents be something like &containers given the fact that we’ve dropped the folder nomenclature?

I prefer staying with "&parents". My logic is that no matter what you call the objects, you will always have to use geneological terms such as parent, child, sibling, ancestor, descendant, etc. in discussing hierarchical relationships; so "parent" will always have a reasonable meaning even if we change the names of the objects (folder, container, super-class, master (vs slave), etc.).

FWIW