I'm starting a a new application, and want to concentrate on making it modular. What I mean by that is that is that in my head I envisage some basic facilities log on, user roles, layouts etc but then I am looking to be able to be able to add self contained "chunks" of functionality e.g. document repository and upload, diary and reminder service .. whatever.
How I've been laying out apps so far is simply everything in root, separate subfolders for images and cfcs, sticking to naming conventions for variable and query names etc, all database interaction via cfcs, doing all my processing at the top of the page, then a comment line then display/page layout below that.
I have tried and failed to get my head around the various frameworks out there, but I just get paralysed with indecision and confused about whether I'm doing it "right". Is there a way of working that has some acceptance of being a useful methodology without getting in to the whole official "framework" thing?
Then you probably want to separate your presentation layer from the core as much as possible. A good and popular way to do this that is picking up speed very fast is following the MVC (model-view-controller) pattern
http://en.wikipedia.org/wiki/Model%E2%80%93View%E2%80%93Controller
This will allow you to modulate functionalities into controllers that are completely seperate from layout, etc. The controllers can then more easily be integrated into other projects as need be.
I know you said you didn't want framework and you most certainly don't need one but I strongly suggest it for larger application such as what you are describing. Some can have so many rules and what not that they seem to get in the way a lot. One that I like, which is based on Ruby on Rails called CFWheel (http://cfwheels.org/).
It's pretty much there to help you structure stuff, you are free to follow the "normal" way or not it won't really stop you. Have a look at the screencasts here: http://cfwheels.org/screencasts
Model Glue is an excellent CF Framework. The google group support + docs are great.
FW/1 is another simpler framework to start learning, not sure about the docs at this point.
Frameworks are definately the way to go. Once you get your head around them, they just feel "right". They tend to make you write better code, and having used a coldfusion framework for a year or so now, I can honestly say I'll never go back to not using one 8-)
Honestly, the frameworks can lead to analysis paralysis quite easily. You can easily over think things. Here is what you do, keep it simple and just bang away at the keyboard. Use your "own" framework. It might not be pretty, but you'll get it eventually and you'll see why the other frameworks exist.
Here is how you start:
Create folders layouts and views. Put all your page layout stuff in the layouts folders (you'll probably have only a few and maybe even one layout)! Put all of your view stuff in the views folder (this will probably look like what you've been doing with a bunch bunch of files not very well organized). The key is that you won't have ANY page processing "top of page" code in your view files.
Your index.cfm will be the only .cfm root. Use a URL variable "event" = action to make your framework go.
In your index.cfm, use a giant cfswitch to determine which "top of page" code to execute (this will be a giant "controller").
mysite.com/index.cfm?event=contactInfo
<cfswitch expression="#url.event#">
<cfcase value="contactInfo">
<top of page code>
<cfset structLayoutInfo["pagetitle"] = "XYZ Contact Info" />
<cfmodule template="/layouts/mainlayout.cfm" attributeCollection="#structLayoutInfo# >
<cfinclude template="/views/contactInfo.cfm"/>
</cfmodule>
</cfcase>
.....
</cfswitch>
Combine this with the cfmodule tag to load your layout. So, all your page requests come in through index.cfm. Index.cfm will do all the top of page stuff and then do a cfinclude to the appropriate view in your views folder. Use the cfmodule tag to load your layout (check out the tag.execution mode stuff for headers and footers).
You'll keep adding features and adding features to your framework. You'll probably move the index.cfm code to a controller folder with a bunch of CFCs that call your database CFCs.
Related
I am currently developing a website. I would like to separate content and presentation. I am currently using a Dreamweaver Template to achieve this. However, I find that Dreamweaver's edit regions are very limiting in the design view. I have found that the same goal can be achieved by including the header and footer of my website.
What are the pros and cons of using includes rather than using templates?
First, if I were to rephrase your question, it's more like asking "Should I by a wire frame of a kite or by the glue to stick together what I'm making?" And then, you ask about the pros and cons of buying the wireframe against buying the glue. There are far too many variables as you can see...
And back on your your question... At some point your template will use include files. And for a start, it's worth knowing what you're thinking... Let's look at some basics.
Web design - usually refers to making websites that aren't really interactive. They don't have server-side elements. So most of the site has 'static' contents. If this were the case, you're better off with DreamWeaver, particularly if you're not into html/css editing.
Web development/programming - starts off with something as elementary as mailing a form, to highly interactive sites like FaceBook. Here you'll need to use some server-side language, usually like PHP, ASP or JSP. The choices are many but you've got to choose your own platform or combination of them.
Now to the second option (above). If for example, you were building a site using PHP, one of the nice things you'll do is to include your header, footer and side panels that need to be repeated across all pages. This way, you'll eliminate the need to re-write those sections. But if you were using a program like DreamWeaver, it does this duplication for you. Yes, it physically copy-pastes those sections into every file that needs it. Of course the end result may not be any different. But as a developer, you will be tied down to the DreamWeaver platform or for that matter, any other specific platform.
On the other hand, if you get used to working with an editor like NotePad++ or GEdit, you may switch between editors at any time. But you have the task of hand-coding everything from scratch. But then again, since you would use include files to bring in your headers and stuff, you save development time as well.
I don't know how much of html/css or php you know, but here's one of my demos to show you how to hand-code a site. This ain't complete but you should get an idea.
Link to the video introduction
Link to the video on youtube
Let's say I'm writing a complex site in django with wikis, forums, ... or writing my own apps that I intend to reuse from different sites.
I really want to create, for example, a wiki page that has a forum at the bottom, or reuse my previously written wiki app with a different graphical layout.
What is the best way to structure my app to allow this kind of reuse?
So far, I have been giving apps their own urls in urls.py. This however does not work if I want to combine multiple apps together in a single page.
Additionally, most of the apps I found online come with their own templates, which has the full html, and do not separate the logic of creating / preparing a context from that of handling a request and generating a reply.
What is the best practice here? What do you do? edit the templates that come from applications you download online? refactor them to fit in your application?
what should I do for my own applications? structure them so they have a method to get the context, and a method to render it?
Django hasn't great support out of the box to component-oriented architectures. I find this problematic some times too. You'll face to problems here.
Architecture
Code
Architecture: As Django is not component oriented, all the apps aren't component oriented neither. The designers and coders for those apps haven't thought about that. So they've just built "views" to interface with their apps. You'll need to get something more "pluggable".
Code: Once you decide to build that, you'll have to find what support you have for that. Most Django apps are pretty well coded, so you won't have much code in views, but abstracted in other places. That way you could reuse that code and build your own components.
Example: Suppose you're working with a third-party Wiki app. That wiki has a view to display highest ranked Tags and other view to create a wiki entry. If the code is good enough (that I'm assuming it is because Django has a pretty good community), you could refactor that to use components. The view to create an entry must be using some Form, that you can plug in your own site. And the view to get highest ranked tags probably uses some utility function, or some Tag manager's method. In that case you could refactor it to your own needs.
Hope it helps.
How can multiple developers work on the same website (CSS, JavaScript, ASP.NET).
We use SVN as source control, but the problem is more in regards of testing and general workflow.
I know we could do unit tests and we have for our API, but I don't see how we can do unit testing for our frontend?
We get a lot of problems in the frontend like:
Developer 1 changes CSS and it messes up CSS for developer 2.
Developer 1 changes JavaScript and components developer 2 made stops working.
Developer 1 removed an ID or a CSS class in C# (code behind) and CSS styling is lost or JavaScript stops working.
It's basically things of that nature.
What we do now is manually test everything in all major browsers and we spend too much time on that.
Any good suggestions on how we can improve our way of working? Keep in mind that it's a website and we are struggling with problems related to that.
This is a management issue rather than a workflow issue.
You need to be proactive at managing the situation and be tough.
You have a source control system in place, what you need to do is:-
Enforce day end (or more frequent if preferred) check ins.
Rollback work if it doesn't work. You have to be tough on this point to ensure the developers understand that you mean it.
You need to actively communicate the above to your team to make sure they understand the new work procedures.
It'd only take a few weeks for it to sink in, after that you can relax the controls.
Introduce releases/iterations/milestones; and publish them only from the repo.
Can you not possibly break the site areas up into segments and assign developer responsibilities to each, even if it means sandboxing the "base" code of the site (framework / main CSS / main JavaScript) and assigning a specific responsibility to it? You can then task developers to keep their CSS / JavaScript separate from the main files and merge them before testing and release.
We've had similar problems where I work and this approach seemed to sort it out for the most part. For each segment we built we created a new folder in each of the respective projects (DAL / BL / Presentation), based on the functionalities / modules / segments, each with their own site content (JavaScript / CSS), but still making sure that some generic styling and JavaScript being available to all developers.
An official Agile project management methodology (like Scrum) has huge benefits in an environment like this, as you get to discuss these issues on a daily basis and, if over-arching requirements for new CSS and JavaScript are identified by all developers, it can be integrated into the site's base content.
I am a computer programmer by training but have been away from web development for a while. I am doing a little bit of background research on various Python web development frameworks. I understand that Django, Grok / Zope 3, and Pylons are all good solid frameworks, but have little in the way of background working with them. Can someone explain to me the difference in approach of the each of the frameworks, and where one shines when compared to the others?
My specific use case is in building a web application that will recommend products to users based on a variety of user supplied information. Thus, it will take a fair bit of user input in the shape of a basic profile, product preferences, attempt to establish social relationships between users. It will also need to support staff uploading products into the system with labeled features that can be then matched to users.
On the last point, would parts of Plone help with providing an interface for non-tech people to upload products and descriptions of the products? Are piece of Plone easy to borrow? Seems like I shouldn't have to reinvent the wheel in terms of having a way for people to upload items for sale / recommendation along with some metadata to describe the items. Thanks for the help.
Based on your background and requirements, I'd advise you to go with something like http://pinaxproject.com/ which is based on Django.
Pyramid (the successor to Pylons) is a very low-level framework and you need to either choose the libraries or write all your application code yourself. For someone experienced this makes sense and gives you full control over your code. But it is a bit of a hurdle if you start from scratch and aren't familiar with the available libraries.
Django and Grok are both high level frameworks, with Django being the more popular choice. If you aren't familiar yet with using object databases or URL traversal, Grok is more time consuming to learn.
Plone is not suited for your use-case. It's a content management system and not a general web framework. Very little of the libraries it uses can be reused in a different context, certainly none of its UI. If you want to provide an engaging user experience with personalized content, Plone isn't for you - that's not what its been build to handle.
Disclaimer: I'm a release manager for Plone and Zope 2 / Zope Toolkit and have used Pyramid but not Django.
Dolmen project is a CMS built on top of Grok. Is very simple, but there are very few that use it. If you go with Grok, you could be able to reuse the GUI.
But As Hanno said, Grok is more time-consuming to learn than Django. Also Django has far more users than Grok.
The advantage of using Grok is that you can profit from Zope Component Architecture almost without writing ZCML and using decorators instead.
With Pyramid/Pylons you get a very simple framework and nothing else. It is a decoupled framework, so you are free to use whatever templating enginge you want (Mako, Genshi, Jinja, Cheetah), you are free to choose sqlalchemy, zodb, mongoDb, etc., and you are also free to choose the url mapping scheme (traversal vs. django-style mapping or a combination of both). You can also use ZCA here if you want. For starters this might become quite confusing or verbose.
Django is a kind of monolithic framework that gives you one way to do stuff. That's why it's easy to learn and a very good option. But, in my experience, you sometimes get to a point where you want to deviate from Django standards and it simply cannot be done without patching a bunch of stuff.
And, as for Zope3, I'd recommend you to download a copy of BlueBream and se how it does for you.
As a Plone user I can say that creating Content Objects in Plone is difficult. There is not much documentation on how to do it and it is complicated. Some recommend using UML and specialized Plone products to make it easier but that introduces yet another dependency.
I mention the problem with content objects because your "products" (not the same as a Plone product) would probably be represented in Plone as a content object which you would need to write yourself.
Plone is best when users and editors are entering and approving text in the form of news articles, press releases, photos etc. When that is the use case there are predefined content objects for such things so one does not need to write them oneself.
--Jonathan Mark
Suppose you are running a Django site, and have a legacy PHP forum to support and integrate into your site, since current Django forum solutions are not mature enough.
What is the best way to do this?
Currently I have a simple view, which renders a very simple template which extends my site's base template, and the content area has nothing but an <IFRAME> which holds the forum as its src. A small jQuery function is used to maximize the <IFRAME>'s height (once it finishes loading) so as to contain 100% of the forum content.
But all of this sounds pretty awkward. How would you go about this?
There are a few options. None are ideal (but mixing two platforms never is!)
Use iframes as you've suggested (bad as the address in the address bar is always that of the django page and if somebody copes a link off the forum, it will be the PHP forum, not the django holder)
Use iframes but instead of using the same src all the time, parse the URL and append the relative bit onto the src of the iframe. ie if django sees /forum/this-url, set the src to http://forum-address/this-url and make sure all your links target parent. This has the advantage of showing the correct link in the address bar at all times (rather than it always being /forum/). You'll need to hack your forum for this to work.
Proxy the content and inject it into the page properly. You'll need to pass cookies and it might get really messy but in most terms, this is a great way to integrate things because your links will always be correct. You'll need to butcher your forum theme to strip out everything outside and including the <body> tags.
Theme your forum in the same way as the Django site. This would give best performance but you might have issues if you use dynamic stuff in your django template. An option to get around this is by having the django template cache things to memcache and using php-memcache to pull them out into your forum template.
I have done both 3 and 4 in the past. I used 3 for a very simple form (so didn't have to deal with cookies and sessions as you will). I used 4 for integrating a FluxBB forum into a Wordpress install. Both PHP but it would be uber bloat to load FluxBB inside Wordpress. I cached the dynamic template things into memcache and pulled them out in the forum template.
For this, I would probably suggest going with #4. It's a pain in the arse having to maintain two themes but it's by far the fastest performing solution.
When I read the question summary I immediately thought that you would need some kind of script, which could be linked to a signal via the Dispatcher in Django, to syncronize the user database from your Django site to the forum. This would keep the authentication side of things in check - but you still need to do one of the things that Oli has suggested, to make them look the same.
Themeing will probably be the least hassle-free route, but that's not to say it will be easy!