Personally, I think the prefixes are very useful because at a glance, you
can tell immediately what type of placeholder you're dealing with. Granted,
there are some instances that are easy such as <a
href="<%easy_to_identify_placeholder%>">Link</a> but there are others where
there are numerous possibilities and without a prefix, the only way to tell
what they are is to open them for editing. Using your example of "PageCreated".
What is that? An info placeholder? A standard field? Does it contain text or
a date? With an inf_ in front, you immediately know it's an info placeholder
and add "date" on the end and you know within half a second exactly what
that placeholder is going to return.
In the end, I guess it really comes down to what you're used to and what
you're more comfortable with.

Cheers,

G.

2009/12/13 Richard Hauer (5 Limes) <[email protected]>

> Snaps to Gavin!  Ours is super close.  I think this is a throwback to
> the original training course some of us did way back when RedDot was a
> company not just a distant memory of the name of some software.
>
> Differences highlighted with a *
>
> anc Anchor
> ar Area *
> att Attribute
> brs Browse
> con Container
> db Database
> fra Frame *
> hdl Headline
> hit Hit List
> img Image
> inf Info *
> lst List *
> med Media
> opt Option List
> pjc Project Content
> smp Site Map
> stf Standard Field
> dat Standard Field - date
> num Standard Field - numeric
> txt Text
> tfr Transfer *
> xms XCMS Project Content *
>
> General programmic practice suggests that prefixes are most often
> found in non-typed languages, where the prefix can be used to identify
> type to a consumer of the variable - this is known as hungarian
> notation (I believe because of the sz that prefixes strings which
> stands for "null terminated string" where the null string in also
> represented as '\0' i.e. zero and hence "z".  I think it was
> accidentally also invented by a Hungarian).
>
> Microsoft's naming convention recommendations for .Net Framework
> programming suggest that Hungarian notation is not required, because
> the editor makes it easy to determine the type at design-time, and the
> framework prevents inappropriate use of type casts at runtime (i.e. it
> is a type-safe language).
>
> I would suggest that RedDot (or whatever you want to call it) is more
> like a type-safe language than not, since we have icons identifying
> the type of each placeholder and the runtime manages conversions where
> they are allowed anyway.  This makes it a bit redundant to identify
> placeholders by type in the CMS (by using silly prefixes).  So, in the
> absence of allowing spaces in the name I would suggest that we only
> really need camel-case naming for elements and that the whole prefix
> system could be entirely abandoned.
>
> Examples:
>
> ye olde name          ->     new sexy name
> ------------------                 ---------------------
> lst_Navigation         ->      NavigationPages
> stf_PageTitle          ->      PageTitle
> inf_PageCreated    ->      PageCreated
>
> I don't really see how the prefix is adding any value...
>
> HTH.
>
> Regards,
> Richard Hauer
> ====================
> 5 Limes Pty Limited
> www.5Limes.com.au
>
> PS.  While saying this, actually, we are still using the prefixes in
> our real projects... all I'm suggesting is that it's probably
> unnecessary (and always has been).
>
>
> On Dec 12, 1:54 am, Gavin Cope <[email protected]> wrote:
> > Suggested CMS element prefixes (naming convention)
> >
> > When creating and naming placeholders we recommend the following naming
> > convention followed up an underscore then the name of the element
> (example:
> > anc_linkname):
> >
> > anc Anchor
> > area Area
> > att Attribute
> > brs Browse
> > con Container
> > db Database
> > frm Frame
> > hdl Headline
> > hit Hit List
> > img Image
> > info Info
> > list List
> > med Media
> > opt Option List
> > pjc Project Content
> > smp Site Map
> > stf Standard Field
> > dat Standard Field - date
> > num Standard Field - numeric
> > txt Text
> > xfr Transfer
> > xcms XCMS Project Content
> >
> > 2009/12/12 Ingo Hillebrand <[email protected]>> Hi,
> >
> > > i once saw a list of abbreviations for all RedDot-Elements. Can any one
> > > provide me the link or a selfmade list? The aim i am following is to
> > > create and or to meet international standard.
> >
> > > Thanks in advance,
> > > Ingo
> >
> > > --
> >
> > > You received this message because you are subscribed to the Google
> Groups
> > > "RedDot CMS Users" group.
> > > To post to this group, send email to [email protected]
> .
> > > To unsubscribe from this group, send email to
> > > [email protected]<reddot-cms-users%[email protected]>
> <reddot-cms-users%[email protected]>
> > > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/reddot-cms-users?hl=en.
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "RedDot CMS Users" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<reddot-cms-users%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/reddot-cms-users?hl=en.
>
>
>

--

You received this message because you are subscribed to the Google Groups 
"RedDot CMS Users" 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/reddot-cms-users?hl=en.


Reply via email to