We're designing an app that will generate lots of different types of text output, eg email, html, sms, etc. The output will be generated using some kind of template, with data coming from a db. Our requirements include:
Basic logic / calculated fields within template. Eg "ifs" and "for" loops, plus some things like adding percentages for tax etc
Runtime editing. Our users need to be able to tweak the templates to their needs, such as change boilerplate text, add new logic, etc
Multi lingual. We need to choose the correct template for the current culture.
Culture sensitive. Eg dates and currencies will output according to current ui culture.
Flexibility. We need the templates to be able to handle multiple repeating groups, hierarchies, etc.
Cannot use commercial software as a solution (e.g. InfoPath). We need to be able to modify the source code at any time.
The app is c#.net. We are considering using T4, XML + XSLT or hosting the Razor engine. Given that the syntax cant be too overwhelming for non-techie users, we'd like to get your opinion on which you feel is the right templating engine for us. We're happy to consider ones notalready mentioned too.
Thanks.
I'm very hesitant to try and answer this question on a forum, because technology choices depend on far more factors than are conveyed in the question, including things such as attitude to risk, attitude to open source, previous good and bad experiences, politics and leadership on the project etc. The big advantage of XSLT over Razor is that it's a standard and has multiple implementations on multiple platforms (including at least three implementations on .NET!) so there's no lock-in; but that doesn't seem to be a factor in your statement of requirements. And the fact that you're using .NET suggests that supplier lock-in isn't something that worries you anyway.
One thing to bear in mind is that non-programmers often take to XSLT a lot more quickly than programmers do. Its rule-based declarative approach, and its XML syntax, sometimes make programmers uncomfortable (it's not like anything they have seen before) but end-users often take to it like ducks to water.
We've decided to go with Razor Hosting. The reason why I've posted this is an answer is that I thought it would help others if I include the following article link:
http://www.west-wind.com/weblog/posts/2010/Dec/27/Hosting-the-Razor-Engine-for-Templating-in-NonWeb-Applications
This excellent piece of work by Rick Strahl makes it really easy to host Razor.
Related
While learning Sitecore I have found that the majority of Sitecore sample code on the web is in XSL instead of .NET.
What would be the advantage of choosing XSL over the processes I have become accustomed to as a .NET developer?
Are there processing speed advantages to using XSL?
Is XSL actually easier once you are comfortable with the syntax?
I'll just add my 2 cents too:
I find that there are too many limitations in XSLT that need to be overcome with either external "libraries" or with you developing a method in C# that can be used in XSLT.
So I find using Asp.Net simpler. But then I'm also a lot better with Asp.Net than with XSLT.
But XSLT has some good things:
good when getting fields from the current context item
good with simple content etc.
doesn't force the solution to recycle/rebuild
usually a nice way it fails, ie. the page still works, but the xslt that failed says it fails
When I first started working with Sitecore, my company used quite a bit of XSLT, but we've slowly gone away from that, because of it's limitations and because most people here are more familiar with Asp.Net/C#.
Some folks prefer XSL because of existing team skill set, the availability of XSL talent, or the belief that XSL is easier or cheaper to learn.
In Sitecore, ASP.NET-based sublayouts actually perform much better than XSL renderings. If that's what you are comfortable with, go for it. I've never created an XSL rendering myself.
XSLT is a powerful language; its main advantages over languages like ASP.NET tend to come when you want to reuse and customize logic over a wide variety of different pages or different source document structures with common shared elements and other variable structures. To achieve this it uses a rule-based processing model which some people find quite difficult to get to grips with on first encounter. Learning it is an investment that will pay off over time, but it can be daunting at first.
As for performance, I've never come across a site where it isn't fast enough for the job, and that includes some pretty high-stress services; when people have had performance problems they've usually turned out to be in other parts of the processing pipeline (or simply due to bad coding).
The choice between XSLT and .Net components in Sitecore is largely one of taste and skillset. XSLT in Sitecore does have some drawbacks though - it tends to be outperformed by .NET components for all but the most simple renderings and the places where it might seem most logical to use it, such as replicating content tree structure as a site menu, are actually those that tend to take the biggest performance hit. In the right situations XSLT is an incredibly powerful tool and well worth learning, but I've yet to see a convincing argument for making much use of it in Sitecore. It's also worth noting that some of the standard patterns of XSLT programming aren't the most efficient in Sitecore.
The only real advantage I can think of, would be that XSLT renderings are easier to deploy in isolation. Say, for instance, that you're updating your "News Spots" rendering and you want to deploy this change to test/production right away - it would be a simple case of uploading the .xsl file itself.
Using .NET development (and enduring the Web Application Project model), a deployment of the code base would implicitly deploy any and all changes to the affected assemblies - including whatever work you have in progress.
There are, of course, ways you can manage this. Source code branching/merging and so on - but that's an additional layer of complexity to your solution.
That being said, I use .NET for well over 95% of all my Sitecore development myself :-)
"In summary, a primary goal of software design and coding is conquering complexity. The motivation behind many programming practices is to reduce a program's complexity. Reducing complexity is a key to being an effective programmer." -Steve McConnell (1993)
Let that guide when to use XSLT over C#.
Has anyone of you done evaluation of a django project and how to improve/refactor it's code base? A pet project in company I work at is becoming more widely used and it would be good to improve its quality before further development. Are there any techniques or methodologies of analyzing django projects before we start putting more and more features into it? We wouldn't like to suddenly realise, that due to earlier poor choice we have to live with something really bad.
What I noticed after working more than a year on a quite large site was mostly this concerning our design/coding. It's not purely refactoring related and probably you already know a lot, but maybe it can help :).
Most importantly, we did not always put our code in the right place. There was too many functionality in the view methods, too few in forms and models. I see this problem many times. To handle input, use forms, to format/tweak/... model data, use model methods or properties. Seriously, at one moment I reduced a view of about 150 lines to 20 by just putting code in better places. Improves maintainability and readability very well
Many code we wrote actually did not really use the full force of python and/or django. For the first one, reading something like Dive Into Python was a great help, for the second one I just tracked down all complex constructs we built (mostly legacy code from 0.96) and looked if there were alternatives in the django docs. Of course, don't waste your time trying to reduce everything to a one-liner, but certainly with legacy code this can help improve readability and maintainability.
Always look on sites like django-snippets, google code, ... if there are decent existing django projects that can take away a lot of your functionality. Often these projects are looked upon by more people and are therefore more stable and performant. If a project doesn't meet all your demands it can even be a good idea of just adding your requirements yourself instead of doing it all custom for your site.
Try to keep the application cross-over dependencies minimal. When you would draw a dependency graph (e.g. by linking each app that have foreign keys to each other) it should still be clear and not something where every app is linked to any other app. Typically you'll have some 'helper' apps (e.g. user system, tagging) that are used by many and all other apps are actually only dependent on those apps.
Write tests, django has an excellent test suite, so use it. Certainly for parts of code that are common to many apps and are likely to change. Really, nothing so annoying as suddenly noticing a bug you actually solved 4 months ago and you have no clue which update since then broke it again.
Take a second look at database normalization, the django orm model is still tightly coupled to relational databases and so it's an important concept, certainly when you work with models that are likely to be expanded later on.
Concerning real refactoring, the only important tool I can think of is South, can help you a lot if your database scheme changes. Otherwise, like a hint I already gave: write tests to make sure your functionality before and after refactoring remains the same.
You can learn about code smells. Some folks say that if your code smells it means you need to consider refactoring.
This is very wide subject in fact. Remeber that:
Premature optimization is the root of all
evil -- DonaldKnuth
I personally think that this is also valid for (premature) refactoring.
EDIT: this is also a good resource about code smells: http://www.codinghorror.com/blog/2006/05/code-smells.html
I wish to present the idea of MVC to a bunch of old C++ spaghetti coders (at my local computer club).
One of them that has alot of influence on the rest of the group seems to finally be getting the idea of encapsulation (largely due in part to this website).
I was hoping that I could also point him in the right direction by showing him Model View Controller, but I need to do it in a way that makes sense to him, as well as it probably needs to be written in C/C++!
I realize that MVC is a very old architectural pattern so it would seem to me that there should be something out there that would do the job.
I'm more of a web developer, so I was wondering if anybody out there who is a good C/C++ coder could tell me what it is that made the MVC light switch turn on in your head.
Don't start off with MVC. Start off with Publish / Subscribe (AKA the "listener" pattern).
Without the listener pattern fully understood, the advantages of MVC will never be understood. Everyone can understand the need to update something else when something changes, but few think about how to do it in a maintainable manner.
Present one option after another, showing each option's weaknesses and strengths: making the variable a global, merging the other portion of code into the variable holder, modifying the holder to directly inform the others, and eventually creating a standard means of registering the intent to listen.
Then show how the full blown listener can really shine. Write a small "model" class and add half a dozen "listeners" and show how you never had to compromise the structure of the original class to add "remote" updates.
Once you get this down, move the idea into to the "model view" paradigm. Throw two or three different views on the same model, and have everyone amazed on how comparatively easy it is to add different views of the same information.
Finally discuss the need to manage views and update data. Note that the input is partially dependent on items which are not in the view or the model (like the keyboard and mouse). Introduce the idea of centralizing the processing where a "controller" needs to coordinate which models to create and maintain in memory, and which views to present to the user.
Once you do that, you'll have a pretty good introduction to MVC.
You might find it easier to sell them on the Document/View or Document/Presenter patterns. MVC was invented on Smalltalk where everything about the different UI elements had to be coded by the developer (as I understand, never used the thing). Thus the controller element was necessary because didn't have things like TextElement::OnChange. Now days, more modern GUI API's use Document/View but Document/Presenter is something I've seen proposed.
You might also consider reading Robert Martin's article on the TaskMaster framework.
You might also consider that any C++ developer who is not familiar with these patterns and already understands their purpose and necessity is either a complete newb or a basket-case best avoided. People like that cause more harm than good and are generally too arrogant to learn anything new or they already would have.
Get some spaghetti C++ code (theirs?), refactor it to use MVC, and show them what advantages it has, like easier unit testing, re-use of models, making localized changes to the view with less worry, etc.
This is related to this question:
how-can-i-port-a-legacy-java-j2ee-website-to-a-modern-scripting-language
but with a narrower focus.
We're pretty much rewriting our legacy Java app from the ground up for a variety of reasons, but attempting to keep the user interface pretty much the same.
In one of the answers, someone said:
Pick representative pages and rework them into the appropriate templates. You might make use of some legacy JSP pages. However, don't waste too much time with this. Use the HTML to create Django templates.
The thing is, the application has about 15 different "front pages", each of which is largely composed of an appropriately mixed&matched subset of ~100 jsp files. I believe the partitioning of content in the jsp files is probably the partitioning that I would want to use for the Django templates; thus I'd rather convert them to templates than start with the HTML and re-do the work of figuring out the proper partitioning.
So, I'm really hoping there is a reasonable way to do this conversion.
I'm a Django newbie & have never worked with javascript (tho other folks on my team have), so any help would be greatly appreciated: if you can recommend an automated or semi-automated tool, or suggest a basic approach, tips & tricks, advice, horror stories..
Thanks in advance!
Edited in response to Vinay's answer:
I think it is fairly vanilla jsp, with no third party libraries involved.
There are scriptlets, but they are well-segregated into their own files.
At this point I think we want something quick that we can improve
to best-practices later.
Regarding EXTENDS versus INCLUDE, this makes me think that we ought to
think carefully about the design of our front pages, at least; but can
take a least-effort approach to converting some of these small snippets.
You might be on a hiding to nothing - it'll certainly depend a lot on the details, e.g. your use of third-party libraries and custom JSP tags. Do you just want to implement it in Django with minimal work, or do you want the finished site to reflect Django best practices? For example, in Django it's common practice to design templates using their extends feature - although Django does have an include tag which is analogous to <jsp:include/>, one sees extends more often and include much less often. In the JSP world, the extends functionality is not part of vanilla JSP and is implemented using third-party libraries e.g. SiteMesh or Tiles.
If I were faced with the task of "get something that works - fast!", my first approach would be to work up a Python script which parsed all the JSP files (using a fairly unsophisticated parser based on regular expressions) and spat out the equivalent Django template files, flagging up the hard stuff as it goes. It probably won't be pretty and it won't do everything well, but it'll be systematic and you'll get a checklist to things which need to be done by hand (e.g. template tags which need to be implemented). The likelihood of this approach adding value is proportional to how tidy and systematic the JSP code is, whether you use scriptlets at all, and so on.
I feel the need to refactor my old CF5 based code into CFC's. We already have some code in ColdSpring and Transfer but feel a large rewrite to ColdSpring and Transfer is pointless.
What tips, approaches and gotchas will I hit.
How can I make this easy?
I don't mind keeping ColdSpring in the mix but Transfer is the bit I'm scared of with the size of the project.
edit: my code base has been going for 7-8 years and is vast. To describe it would be difficult, however I'm looking for generic suggestions on approaches
Changing the whole code base just for the sake of it if it basically works would be introducing a lot of potential bugs into your system. I don’t think there is an easy way to do it.
If you look at the areas of your site which are 1: most likely to change and 2: executed the most you may be able to target some areas which could benefit from change and see how easily they would fit into a CFC based framework, and what benefits. But for most of the code if it is working OK, there may be no pressing need to change.
However whenever you need to do a major alteration to part of the system it may be worth looking at that from an OO perspective and moving the existing code over, where applicable.
In one of my ongoing projects (almost same situation, even more -- most of code is really bad) I am using technique I'd called "wave-style". General ideas I use are following:
Splitting processing from output. I can not implement true MVC here, but at least I can move view into separate templates (sometimes re-use them) and prepare all data in basic (model) templates.
Move all repeating code into components -- this is one of most important tips.
Group related functions into components. Say, all customer-related info grouped into CustomerManager.cfc, invoices into InvoiceManager.cfc etc.
Why "wave"? In a big project I can't just sit and rewrite all customer-related code. So I have make it step by step. For example, I have to work on customer signup, extend it with few attributes. I've created basic component, moved there methods to validate form (check login, email etc.) and add customer - so this page works in new style. Lated I will need to improve invoice page, where I need to get invoice owner details: I just add method into customer manager and get rid of direct queries. Later edit customer page... Also it can be called "on demand refactoring" or smth.
There can be additional stuff relying on your current project state. But it helped me a lot. Hope you'll find these tips useful.
Before you change anything: create a full set of regression tests!
When refactoring, the goal has to be preserve functionality first, so that you don't directly affect your clients.
I agree with Sergii's wave-style refactoring also - this allows you to break things into manageable chunks rather than doing everything in one go.
But whatever method you have, the more regression tests you can create, the better - it's really the only way you can confirm you haven't unintentionally changed something.
This is extremely hard (bordering on impossible) to answer without knowing any of your code.
The question is a bit like "I want to disassemble my old Volkswagen and build a new one from the parts, what should I consider?" :-)
My advice would be to start off by encapsulating your business logic into CFCs instead of worrying about the whole presentation layer of your site.
By just concentrating on the business logic, you'll be able to get the most important functionality into CFCs and ease the maintenance nightmare. It also won't be too hard to just "drop-in" these CFCs into your existing site.
After getting as much business logic into the CFCs as you can, you'll notice that the enormous monster has been cut down to size. At that point you can now decide on what you want to do with the presentation layer of your site. You're now free to pick from a multitude of frameworks available to use (CFWheels, FuseBox, ColdBox, Mode-Glue) to port over the presentation layer.
Or you could just say "the heck with it" and rewrite the whole thing in CFWheels from the start :)
If you are not using version control get that set up before you do anything else. Being able to back out of broken refactoring is a serious life saver. After that I agree with what has been posted. You will want to take on small chunks at a time - divide and conquer.