What is common name for the patterns in CMS contents? Like:
Hello {{FIRSTNAME}}
Your order was sent to:
{{ADDRESS}}
Are these
variables
patterns
blocks
placeholders
macros
or what
I think it depends on the system and your environment.
In a programming environment I would name them variables and all around is the template.
But placeholder is also okay, especially if you talk to non-programmers.
HTH.
Related
I was assigned the task to rewrite our home-made templates with Perl Template Toolkit.
Our templates have the possibility to extract a fragment of the template (and then make HTML from it) instead of using the entire template.
How to do it with Template Toolkit?
The best solution I came with is the following:
Let we have a template x.html with fragment A.
The fragment should be extracted into new file. (I am to name it like x/A.html for consistency.) In the original template x.html it should be replaced with [% INCLUDE 'x/A.html' %]. So I could be able to use either the entire template x.html or its fragment x/A.html. Probably we may have several levels of inclusion like x/A/B.html.
Are there other ways to do it? (I don't like to idea to split it in subdirectories as described above, but haven't come up with a better solution.)
Are you asking whether there's a better way to extract the fragment from the parent template?
(Answer is: no, that's probably the best way.)
Or are you asking is there a better way to organize the extracted fragements?
(Answer is: no real best answer, everywhere will have their own house style - you aren't going to go too far wrong by picking any convention.)
Most common conventions for naming I've seen are subdirectories x/A.html and prefixes x_A.html. Whether you use the name of the parent template for x or you choose to group by functionality as simbabque suggested is another matter of taste: grouping by functionality scales better on larger and more complicated layouts where you have a great deal of reuse of components, but grouping by use case is conceptually simpler in smaller use cases with little or no component reuse.
I realize that it is impossible to have one language that is best for everything.
But there is a class of simple programs, whose source code looks virtually identical in any language.
I am thinking not just "hello world", but also arithmetics, maybe string manipulation, basic stuff that you would typically see in utility classes.
I would like to keep my utilities in this meta-language and have it automatically translated to a bunch of popular languages. I do this by hand right now.
Again, I do not ask for translation of every single possible program. I am thinking a very limited, simple language, but superportable.
Do you know of anything like that? Is there a reason why it should not exist?
Check Haxe, and its Wikipedia page. It's open source and its main purpose is what you describe: generating code in many languages from only one source.
Just about any language that you choose is going to have some feature that doesn't map to another in a natural way. The closest thing I can think of is probably a useful subset of JavaScript. Of course, if you are the language author you can limit it as much as you want, providing only constructs that are common to just about any language (loops, conditionals, etc.)
For purposes of mutability, an XML representation would be best, but you wouldn't want to code in it.
If you find that there is no universal language, you can try a pragmatic model-driven development approach, using a template-based code generator.
On the template you keep the underlying concepts of an algorithm. Then, you would add code for this algorithm in one or more specific languages (C++,Java,JS,Python) when necessary. You would have to do it anyway, whatever the language or approach you choose. A configuration switch would pick the correct language for any template you apply.
AtomWeaver is a code generator that works with templates and employs ABSE as the modeling approach.
I did some looking and found this.
https://www.indiegogo.com/projects/universal-programming-language
looks interesting
A classic Pascal is very simple. Oberon is another similar option. Or you could invent your own derivative language similar to the pseudocode from the computer science textbooks. It's trivial to implement a translator from one of that languages into any decent modern imperative language.
I use CodeSmith for the PLINQO templates, to build my DAL from my DB objects; it works great!
I believe that's the primary use of code generator apps, but I'm curious... what other code would you consider using a code generator for? Do you have any CodeSmith templates that you use frequently (if so, what does it do)?
I haven't used CodeSmith, but I've done a fair bit of code generation. Noteably I wrote most of a configuration management (CM) system for a WiMAX system, where the CM code was generated for 3 different platforms. The only difference was the CM model for each platform.
The model was in a custom Domain Specific Language (DSL) that we built had a parser for. The language was a basic container/element style where containers could nest and have an identifier, and elements were of pre-defined types. Documentation was an attribute of elements and containers. You could add Lua snippets to the element and container definitions to do semantic validation (e.g., the value is in the correct range, if it's an IP address is it in a CIDR range defined elsewhere, etc.).
The parser generated a syntax tree that we then pushed at templates. The template language was a partial C implementation of StringTemplate. We used it to generate:
A model specific C API that applications could call into to get configuration values,
The collected Lua code for validating the model and providing useful error messages,
Two "backends" for the API that would manage values in memory (for temporary manipulation of a model), and in a database system (for sharing amongst processes),
Configuration file parser and writer,
HTML documentation, and
Command Line Interface (CLI) implementation for interactive viewing and changing of a configuration.
In retrospect, I should have simply used Lua directly as the DSL. It would have been more verbose, but having the parser already there and lots of Lua templating choices available to me would have saved a lot of development effort.
For things that have a repetivie structure and well defined rules about what those things need to do, code generation can be a wonderful thing.
I need to define simple classes and interfaces (Ex. IClassInterface) in a language neutral way and then use a variety of code generation tools to generate the code files in a variety of languages such as C#, Java, etc... Does anyone know of a standard; ratified or otherwise; that I can use for the neutral representation. I know UML is often used for creating diagrams, but I am actually looking for something that can easily be parsed, extended, and used to drive other automated processes. Maybe this is actually possible with UML, although I am not sure what the markup language might look like if one exists.
I could create my own definition using XML or something similar, but I would prefer to avoid reinventing the wheel if possible.
UML
I think you might be looking for XMI (XML Metadata Interchange)
There is IDL (for example, Google's protocol buffers), and WSDL, which can be used to produce interfaces and classes by many web service frameworks. (You typically do not have to use the generated code as an actual webservice.)
The wikipedia entry for IDL lists a number of implementations of IDL. Although IDL is mainly for describing interfaces, some implementations also use it to describe objects (e.g. Microsoft IDL.)
I have created some of my own user packages and have run into a name clash.
In Java, the naming convention is to use your domain name in the package name:
e.g. import com.example.somepackage;.
Are there any widely used package naming conventions for common lisp packages?
Regards,
Russell
The convention I use is to use a unique word: salza, skippy, zs3, etc. I don't really try to have a direct relationship to the library functionality. I try to avoid generic words that others might use like "zlib" or "zip" or "png".
Edi Weitz uses Frank Zappa-related words to name many of his packages: Hunchentoot, Drakma, etc.
Some people use Java-style org.foo.bar reversed domain naming.
So, the direct answer is no, there isn't a common, agreed-upon convention that everyone uses.
One convention that you see sometimes is packages which provide a thin compatibility wrapper over routinely implemented but non-standardized functionality are often called TRIVIAL-SOMETHING.
This leads to some really wonderful names: the library for working with *FEATURES* in a implementation-independent way is called TRIVIAL-FEATURES; even better, the library for interacting with the garbage collector in a standardized way is called TRIVIAL-GARBAGE.
There's no general convention, but there are a few patterns:
When the library is a port from some other language, a wrapper or an interface library it is often prefixed with cl-, like cl-gtk2 or cl-ppcre. Although there was a time, when this prefix got abused, and there are a lot of packages (e.g. cl-who), that implement a unique functionality, but still use it.
If the package is implementation-specific, it's prefixed with implementation shorthand (most notably: sb-), like sb-queue or lw-compat.
If the package is a compatibility layer between implementations, it is often prefixed with trivial-, like trivial-backtrace or trivial-garbage
There's also s- prefix, which may stand for 'symbolic', like s-xml, but it's rarely used.
These prefixes help making the name of the package unique and thus simplify finding information about it on the web.
Otherwise there are no specific conventions, but the general rule is to favor short, unique and, probably, descriptive names. For the reasons of ease of remembering, usage and finding information.
If the package happens to have a long name it's handy to provide a shorter nickname, because more often, than not people will use package's symbols qualified by their names. For example in my code I add a nickname re to cl-ppcre, and it makes the client code much more understandable and clear. Although caution should be applied, so that nicknames didn't cause name-conflicts.