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
I am a novice web designer who has a history of creating websites using templates and WSIWYG programs like Dreamweaver. So I know some basic html and a little flash. But that's it - I DO NOT know CSS or CMS. Mostly I'm a graphic designer. But I'm looking to learn a new web language...
I now have a client who wants me to design a website so that in the future, they can edit the website themselves. I know this is a popular trend these days in the client community. And I know this is the main purpose of web CMS. I am looking to learn a new web language but want to make sure I learn the right one.
My question is, what language do you recommend to build this website -- making it the easiest for the client to edit in the future? What language has the best/easiest interface for a NON-DESIGNER to edit a website? Another matter of note, also, is the flexibility of design creativity on my end.
Wordpress? Droopal? Joomla? I've researched a little bit about Adobe Contribute CS5 as well and thought of this also as a viable option... perhaps?
Thoughts? Suggestions?
In depth info would be awesome! Pros/cons of popular languages, common uses for popular languages (blogs, ecommerce, etc.), links to further knowledge, references, etc.
Thanks!!
Without a doubt, you should start with Wordpress.
You may take a look at this google trends comparison: https://trends.google.com/trends/explore?q=wordpress,drupal,joomla
I'm not saying is the best, but Wordpress is VERY popular, it is much simpler to begin with, and I think you'll get much more job offers.
Regarding languages and technologies, Wordpress is PHP powered, so your learning path should be:
- HTML
- CSS
- PHP
- JavaScript / jQuery
And for the future, you might start thinking on Javascript, Node, Angular and React since the internet ship is going that direction (even Wordpress)
My personal recommendation if you wanted to code fancy things would be Python and the Django web framework. However, that's probably a bit more advanced than you can currently handle.
All 3 of the frameworks you've listed are well respected. Which one you choose is really going to depend on what kind of site you're building. If you're building a site which focuses around a blog, by all means use Wordpress. You can add static elements relatively easily, but it shines for episodic content. If you're building a site that has more static "page" type content, either Drupal or Joomla are reasonable choices. I would probably lean a bit towards Drupal. If you tell us what kind of page you're building for your client, we can give you more tailored advice.
As an aside, "CMS" isn't really a language. The systems you're talking about are frameworks. PHP is the language that they happen to be written in.
You won't go wrong with any of the above options.
I would stay away from Adobe Contribute.
There are many good open source content systems such as wordpress, drupal, joomla, etc. They can be customized for your needs. Here are some tips if you want to write your own: learn soke script language like php, perl, python,etc. Php is very user-friendly and there are so much built in functions that make your life easier. You also need some database experience - mysql, postgre, etc. Creating your own cms is a good way to learn a concept, so good luck.
I would definitely start with learning HTML 4 (and 5) and CSS.
For a server side language there are several options. Perhaps PHP is the easiest to start with.
WordPress is a very powerful framework. Joomla is even bigger. It totally depends on the requirements. But if you want to use a framework like Joomla, Drupal, or WordPress, PHP is probably the best language to study. Personally I'd prefer ASP.NET, but that's mostly because I'm already familiar with that framework. I like PHP as well, but it always feels like ASP.NET is more mature. But that's my personal opinion!
Take a look at the features of WordPress, Joomla, Drupal, that's the best advice I can give. You've got the requirements for the website so, after a short study, you are the only one who can make a good decision.
Background:
I have a new site in the design phase and am considering using ColdFusion. The Server is currently set-up with ColdFusion and Python (done for me).
It is my choice on what to use and ColdFusion seems intriguing with the tag concept. Having developed sites in PHP and Python the idea of using a new tool seems fun but I want to make sure it is as easy to use as my other two choices with things like URL beautification and scalability.
Are there any common problems with using ColdFusion in regards to scalability and speed of development?
My other choice is to use Python with WebPy or Django.
ColdFusion 9 with a good framework like Sean Cornfeld's FW/1 has plenty of performance and all the functionality of any modern web server development language. It has some great integration features like exchange server support and excel / pdf support out of the box.
Like all tools it may or may not be the right one for you but the gotchas in terms of scalability will usually be with your code, rarely the platform.
Liberally use memcached or the built in ehache in CF9, be smart about your data access strategy, intelligently chunk returned data and you will be fine performance wise.
My approach with CF lately involves using jQuery extensively for client side logic and using CF for the initial page setup and ajax calls to fill tables. That dramatically cuts down on CF specific code and forces nice logic separation. Plus it cuts the dependency on any one platform (aside from the excellent jQuery library).
To specifically answer your question, if you read the [coldfusion] tags here you will see questions are rarely on speed or scalability, it scales fine. A lot of the questions seem to be on places where CF is a fairly thin layer on another tool like Apache Axis (web services) and ExtJs (cfajax) - neither of which you need to use. You will probably need mod-rewrite or IIS rewrite to hide .cfm
Since you have both ColdFusion and Python available to you already, I would carefully consider exactly what it is you're trying to accomplish.
Do you need a gradual learning curve, newbie-friendly language (easy for someone who knows HTML to learn), great documentation, and lots of features that make normally difficult tasks easy? That sounds like a job for ColdFusion.
That said, once you get the basics of ColdFusion down, it's easy to transition into an Object Oriented approach (as others have noted, there are a plethora of MVC frameworks available: FW/1, ColdBox, Fusebox, Model-Glue, Mach-ii, Lightfront, and the list goes on...), and there are also dependency management (DI/IoC) frameworks (my favorite of which is ColdSpring, modeled after Java's Spring framework), and the ability to do Aspect-Oriented Programming, as well. Lastly, there are also several ORM frameworks (Transfer, Reactor, and DataFaucet, if you're using CF8 or earlier, or add Hibernate to the list in CF9+).
ColdFusion also plays nicely with just about everything else out there. It can load and use .Net assemblies, provides native access to Java classes, and makes creating and/or consuming web services (particularly SOAP, but REST is possible) a piece of cake. (I think it even does com/corba, if you feel like using tech from 1991...)
Unfortunately, I've got no experience with Python, so I can't speak to its strengths. Perhaps a Python developer can shed some light there.
As for url rewrting, (again, as others have noted) that's not really done in the language (though you can fudge it); to get a really nice looking URL you really need either mod_rewrite (which can be done without .htaccess, instead the rules would go into your Apache VHosts config file), or with one of the IIS URL Rewriting products.
The "fudging" I alluded to would be a url like: http://example.com/index.cfm/section/action/?search=foo -- the ".cfm" is in the URL so that the request gets handed from the web server (Apache/IIS) to the Application Server (ColdFusion). To get rid of the ".cfm" in the URL, you really do have to use a URL rewriting tool; there's no way around it.
From two years working with CF, for me the biggest gotchas are:
If you're mainly coding using tags (rather than CFScript) and formatting for readability, be prepared for your output to be filled with whitespace. Unlike other scripting languages, the whitespace between statements are actually sent to the client - so if you're looping over something 100 times and outputting the result, all the linebreaks and tabs in the loop source code will appear 100 times. There are ways around this but it's been a while - I'm sure someone on SO has asked the question before, so a quick search will give you your solution.
Related to the whitespace problem, if you're writing a script to be used with AJAX or Flash and you're trying to send xml; even a single space before the DTD can break some of the more fussy parsing engines (jQuery used to fall over like this - I don't know if it still does and flash was a nightmare). When I first did this I spent hours trying to figure out why what looked like well formed XML was causing my script to die.
The later versions aren't so bad, but I was also working on legacy systems where even quite basic functionality was lacking. Quite often you'll find you need to go hunting for a COM or Java library to do the job for you. Again, though, this is in the earlier versions.
CFAJAX was a heavy, cumbersome beast last time I checked - so don't bother, roll your own.
Other than that, I found CF to be a fun language to work with - it has its idiosyncracies like everything else, but by and large it was mostly headache free and fast to work with.
Hope this helps :)
Cheers
Iain
EDIT: Oh, and for reasons best known to Adobe, if you're running the trial version you'll get a lovely fat HTML comment before all of your output - regardless of whether or not you're actually outputting HTML. And yes, because the comment appears before your DTD, be prepared for some browsers (not looking at any one in particular!) to render it like crap. Again - perhaps they've rethought this in the new version...
EDIT#2: You also mentioned URL Rewriting - where I used to work we did this all the time - no problems. If you're running on Apache, use mod_rewrite, if you're running on IIS buy ISAPI Rewrite 3.
do yourself the favor and check out the CFWheels project. it has the url rewriting support and routes that you're looking for. also as a full stack mvc framework, it comes with it's own orm.
It's been a few years, so my information may be a little out of date, but in my experience:
Pros:
Coldfusion is easy to learn, and quick to get something up and running end-to-end.
Cons:
As with many server-side scripting languages, there is no real separation between persistence logic, business logic, and presentation. All of these are typically interwoven throughout a typical Coldfusion source file. This can mean a lot more work if you want to make changes to the database schema of a mature application, for example.
There are some disciplines that can be followed to make things a little more maintainable; "Fusebox" was one. There may be others.
Not a programming question I'm afraid, so moderators do what you will, but it is a question specifically for self-employed programmers running their own ISV sites.
If you publish your own shareware or freeware, do you use any CMS or templating system to streamline maintaining the website? Would you recommend any?
Two most important features I'm looking for that I couldn't find in any popular CMS/blogging engine, from my favorite TextPattern to WordPress, Joomla and Drupal are:
a templating system to maintain structural consistency of xhtml page layout
a hash table of user-defined values that works with the templates to substitute these values for identifiers.
Explanation: If you publish more than one application, the site probably contains several classes of pages that are nearly identical for each product: "Features", "Screenshots", "What's new", "Download", etc. These pages have the same layout and differ mainly in product-specific data. I'd like to be able to define "CurrentVersion=2.2" for product A, and "CurrentVersion=3.3" for product B in a "dictionary", and have the system generate two "Download" pages from the same template, replacing the "CurrentVersion" identifier with each product's respective value.
Other than that, I am looking for good support for static pages (the example pages above do not yield themselves to blog-like timeline treatment) and for design templates (themes), since I can't do graphic design at all (no skills, no tools, no talent). A good search function, esp. for the FAQs, is important. Another nice-to-have is easy (preferably wiki-like) way of linking to pages within the site. Some CMS-es, such as Joomla, make this simple and common task surprisingly inconvenient.
LAMP, and preferably free, since mine is a freeware-only shop.
I need no collaboration features and no multi-user content editing at all. My ISP doesn't support Zope, so that excludes some candidates.
I'm asking this question having spent months trying to find a solution that would help me leave static html behind and reduce the maintenance chores, such as updating the current version number on several pages manually. So what do others use to publish their software?
(Please do not reply by just saying "Try X". At least please say what makes it suitable or how it is better than other possible solutions. I've already tried a number of CMS engines, and they all seem to require extensive modifications to suit this particular need. Since my programming experience is strictly desktop-side Windows, tweaking these products is well beyond my skills (and my skin crawls to think of potential security WTFs I could unwittingly commit). Time is also a factor, since between my day job and my late-night coding, there's little left for learning how to write my own CMS from scratch - just typing static html would be more efficient.)
Wordpress is quite nice. It has a big community behind it so you can leech some plugins, like for SEO optimization, PayPal integration, Google Analytics statistics tracking, etc. And you also have a full-featured administration backend to manage all your content.
I would recommend Joomla 3.2.x. I have the same sort of project based websites, and this provides the flexibility for all of the different requirements. While WordPress is great the simplicity of it gets the better of it, Joomla is far more flexible and has a huge support network and extensions library.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
What features should "Tomorrow's" wikis include? How might they incorporate Web 2.0 features like AJAX? What other features are they currently missing? What do you want to see from the next release of your favorite Wiki?
Edit: How might a Wiki be integrated into other products? What "neat uses" could wikis have?
Preview-as-you-type works very nicely indeed here on Stack Overflow. Many wikis don't do that.
Make it really easy to link between pages, eg. that, as you type, the wiki finds likely pages you may be referring to. That way you can make links without having to know the exact title of a target page, and bouncing on the shift key to WriteInCamelCase, or throwing in square brackets. Make it very easy to link to other websites outside the wiki, too (and by "easy" I do not mean like wikisisters, which, if I remember correctly, is like foowiki:ALinkLikeThis).
Similarly, if you can generate links within text automatically, you could, for example, have a mail system that wikifies your email. You create a wiki page, say, for Joel Spolsky, and references to Joel emails in your inbox become links to that page, which you can find by clicking "what links here". (This probably needs something along the lines of Bayesian filtering to prune the stray references to other Joels... your Bayesian Classifier learns that if the context is smart and getting things done, it's Spolsky. If it's flying Viking kittens, it's morely likely Joel Veich).
A variety of RSS feeds for tracking changes would nice, too. (Diffs, full text, changes on pages I've edited, ...)
Wikipedia has grown a fairly colossal categorisation system ("Fictional Cats", anyone?); laying a taxonomy over a wiki's flat namespace could provide another way for users to find their way around. Wikipedia's doing this a little, but in fairly limited ways so far: there are links to the relevant category lists, but you can't, for example, look for a composer called "Smith".
Similarly, wikis give you this big graph of interconnected nodes, of how closely your community sees the relevant concepts as being. Is that interesting? Is that useful? Does anyone who isn't google want to think about this stuff?
PS. If you believe Paul Graham's definition of Web 2.0 as "Democracy, Don't Maltreat Users, and Javascript works now", wikis are two thirds Web 2.0 already.
I am personally already tired of wikis. Wiki as a software is outdated, now it is about wiki as a feature (like my favorite new website, stack overflow).
The main advantage of community wiki — more editing — came into existence when we introduced "Suggested Edits".
With "Suggested Edits", anyone, even an anonymous user, can edit anything — so long as another experienced user reviews and approves their edit.
I'm in the process of choosing a wiki tool, and have looked at numerous packages over the past week. I'm sure there are dozens I haven't even heard of yet, probably good ones. But in general, here's my "beginner's mind" take on the problem.
Wiki markup should be abandoned. A wiki that is limited to wiki markup will only be useful to 'nix hacks and others who get excited about doing things the hard way and insisting that everybody else is stupid. I mean, Morse code is fine with me personally; I don't get what was wrong with a nice, clean dash-dot-dash. Or smoke signals, they were nice, except for the carbon footprint. But times change, and we have to change with them.
Real users (business users, customers, clients) want rich text editing. Period. And when a wiki tries to support both rich text and wiki markup, the results are not pretty. The model is confusing and (apparently) difficult to implement. The fckeditor extension at wikiwiki is a nightmare, for example. It's just not worth it.
Wikis need better access control. The idea that all content should be open to everyone is fine for an open, public, non-profit wiki like this one. But in the business world, that's not how it works. Restricting access is not evil, it's reality. Wiki tools need to do a much better job of providing access control: access to pages and groups of pages based on role or group membership, where groups can be formed by anyone on an ad hoc basis and users can belong to multiple groups and pages can be accessible to multiple groups, at the whim of the page's creator.
Those are the two things that I want, above all else, and I haven't found it in open source, at least not out of the box. Which, of course, is why open source is open source.
There's been some interesting work using wikis for testing and software development. EG, movement towards literate programming -- allowing pages to exist as both code and documentation that is compiled down into one or the other (or, I suppose, both simultaneously).
They have a regular session about this at the annual WikiSym conference.
I think one direction of Wikis is going from open ended collections of documents to an "everyone can edit but with more structure" applications like SO.
Another direction that I've seen is more direct integration with other project support tools, so project planning, issue management, and all that stuff.
Personally, I think the next big direction is going to be some sort of multimedia based Wiki, not just a Wiki where multimedia can be embedded in the text.
I really like MediaWiki. It's widely used and free/Free. The markup syntax is straightforward and allows you to do enough basic styling that you don't need to use custom HTML or to use a WYSIWYG. I assume by "sexy web 2.0" you mean Flash/AJAX, but I like MediaWiki because it works cleanly with basic HTML/Javascript (you don't have to wait for custom widgets to load, etc...).
What makes wikis reach their potential of usefulness is the community that develops around them more than the software itself. You need to find a niche where people are both passionate about (but not criminally insane about) the central topic and have enough technical prowess to log on to a website and edit some text.
"Wiki" is ultimately just a pattern:
Open editing by all/most visitors
Integrated revision tracking and rollback to reduce the cost of mistakes
Simple syntax for cross-linking between articles, and auto-creation of stub articles when referenced
That's not a perfect description, but it's a combination that isn't particularly magic. Successful wikis combine those things with a critical mass of people creating and maintaining content.
The next step, IMO, is less about web 2.0 shininess and more about the integration of better structural information. Adding any metadata beyond "this points to that" is an exercise in brute force hand-markup. Maybe microformats? Maybe the development of more structured knowledgebase software that uses wiki-ish editing UI but a smarter backend? I'm not sure, but I think better handling of the structured data is really the next wave.
Extensibility.
Check out DekiWiki, they are doing an excellent job with this.
DekiWiki extensions
The wiki-of-the-future will be completely editable online, concurrently by everyone. Check out EtherPad for a demo of the techonology.
For me, in terms of Enterprise style uses for a wiki, I have a couple of thoughts;
An effective way to keep and synchronise a central, web based wiki with multiple, offline, desktop style wiki's for people on the go
To move towards wiki as a function as opposed to wiki as a system, so we can integrate the wiki collaborative system into other things