aaaand another reason why you should use abbreviations in ENGLISH is because I have worked on projects where people just use their native language (German, French, Hindi) to name an element. THAT is confusing guys! Elements should always be in English!
On 13 Dez., 11:24, Gavin Cope <[email protected]> wrote: > 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%2Bunsubscrib > > > > [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%2Bunsubscrib > > [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.
