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.
Related
I am working on a Flask site I inherited from the last person to hold my position. It is a fairly large project with a lot of code, so any fundamental changes I want to make involve a lot of refactoring and rewriting code. With this being said, are there many tangible benefits in trying to integrate Flask-Security this late in the game? The site seems to have a pretty solid authentication system to me. It already uses Flask-Login, Flask-Admin, Flask-Mail, and a bunch of the other packages included in Flask-Security, so it seems like I'm deciding on whether a small change in functionality is worth all the work of implementing it.
This might not be the right place for it, but I am hoping to hear from people who have used Flask-Security and have a good idea of why it would be beneficial to add it rather than using the packages separately. It probably won't be a high-traffic site, but I don't want to create security risks by making the wrong choice.
Thanks!
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.
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
What are the smashing (pun intended) features of grok that makes it better than django?
how do I know when my project needs grok+zope, or it can just be developed with django ?
Zope was the first object publishing framework evah, and the Zope community has a long experience with Doing Things The Right Way. Zope 2 was the first attempt, Zope 3 was the next attempt, and we are now into the third generation of web frameworks, which includes Grok, BFG and Bobo.
Grok is massive, and has even more modules available that doesn't come when you install the base (and it's in the process of reducing the number of required modules as well, so the footprint gets smaller). BFG and Bobo go the other way around, and are minimalistic frameworks but with easy access to the Zope Toolkit and all the functionalities of Zope.
And although Django is making many of the same mistakes Zope2 did, they are also fixing them much faster, so I completely expect much of this discussion to be moot in five years, because I expect every single Python web framework to use WSGI+WebOb+Repoze+Deliverance+Buildout as a base by then. But even then I'd go for frameworks where I can use the Zope Component Architecture and ZODB, but that includes not only the ones made by the Zope community, but also for example Turbogears. And maybe it will include Django too by then, who knows... :-)
Depending on what the project requirements are I would today go with either Plone (if they need CMS), Grok or BFG (depending on the involved developers, and the complexity of the task and the budget). This is of course partly depending on my large experience with the Zope technologies and my small experience with Django, but mostly because I can use ZTK and ZODB in Grok and BFG.
YMMV, etc, blahblah.
Zope Toolkit
Brandons talk on the Zope Component Architecture (Video from PyCOn, Slides from PloneConf)
BFG
Bobo
Grok is basically all the power of zope in a way easier to use package. So you do get all the luxury of a real python object database (though you can use an sql backend). And I assume you know about the adapters/utilities/views of the so-called "zope component architecture". Those allow you to make a robust application. Especially handy if you later need to selectively customize it. And security is traditionally a zope (and thus grok) strong point. Development and deployment are handled fully with eggs (and buildout): in my experience this is a robust and reliable and repeatable and comfortable way.
If you have an application that can work with straight sql tables without needing much selective customizing afterwards: nothing wrong with django. You'll have to do much security yourself, so that needs a keen eye. There's much less of a framework behind it (an ORM and a url mapper), so your python will feel more "pure and simple". This also means you need to do more yourself.
There's nothing from stopping you from selectively using parts of grok: http://pypi.python.org/pypi/grokcore.component for instance is very much the core. Pretty well isolated, so you can use it without buying into the whole zope stack. I'm pretty sure you can use that in django. grokcore/zope component is just python code. This gets you the adapters/interfaces/utilities. I don't know what you're building, so you'll have to experiment.
One thing hugely in favour of grok that I'd suggest trying out: zope's ZODB object database. A good ORM (and django's is pretty ok) helps a lot taking the pain out of SQL databases, but a real object database is just plain luxury :-)
I don't think any of the frameworks are intended to have any 'features' that make one 'better' than the other, or 'needed' in certain circumstances. Rather, the difference between Django and Grok - or Pylons, or Turbogears - is really one of approach. You may find the approach of Grok to your liking, or you may prefer one of the others. I doubt there is much you can achieve in one of them that you can't in any of the others.