Please Help Me To Determine What Type Of Programming Is Needed

[Powerband]

Is been a long long time since i've been involved with making websites. Back then it was just html with a bit of java scattered here and there. - things have changed.

I want to create a website and am lost as to what type of programming is required, any help out there to steer me in the right direction is tremendously appreciated.

The website will be similiar to a classified site (but it isn't) where there are pictures and information about the product, and will allow you to send correspondance back and forth between the company/owner of the product.

There will have to be a fee to be paid before access is granted, so i need to integrate a username and password and put up a firewall to stop hacking into the system, or whatever its referred to nowadays.

The system will require that you log in everytime you visit, and there will have to be sometype of way to determine if the membership fee as expired.

Sorry for the ambigous information, any help to provide me info and kick me in the right direction is extremely welcomed.

[kiwiinasia]

You need an e-commerce type website from the sound of it.

Search the internet for "open source ecommerce", there are hundreds, never pay for one!

PHP based seem to be the most popular.

If you have a webhost in mind ask them what they support/recommend.

[robblok]

PHP and MSQL database is my guess.

I know loads of people who make these as i do their accounting. Some are better then others, and to be honest most Europeans are light years ahead of the Thais. This is not bashing but simply stating the truth. Just compare European websites with Thai ones.

[Jdietz]

Have a look at AJAX (asynchronous JavaScript and XML), it's currently state-of-the-art for designing interactive web pages.

[Gigabyte]

I would start with a LAMP server from scratch (Linux Apache MySQL Perl/Python) because it's all free and so powerful and well supported (the web wouldn't be the web without that) however not everybody would agree with me... :-)

Edited February 14, 2010 by Gigabyte

[markwhite]

As others have said, you'll probably end up on something like PHP/mySQL and using a bit of Javascript/AJAX for pretty stuff.

However if these are all new to you, I would recommend looking at some of the Content Management Systems that are available out of the box. The ones I've come across are built on PHP/mySQL and can have a wealth of plugins and addons that can allow you to have a lot of advanced fuinctionality that might not be easy to do yourself. There are bundles of website templates available too, which can be customised relatively easily.

The main one I've worked with before is Joomla. That doesn't mean it's the ideal solution for what you're hoping to do, but something like this might cut down development times and costs (lots of plugins are free) immensely. And though it will present it's own learning curve, I didn't find it too bad. Drupal has also been recommended to me, but Joomla seemed much simpler to me at the time.

And Joomla installs real easily on a WAMP/LAMP setup.

[siamect]

As others have said, you'll probably end up on something like PHP/mySQL and using a bit of Javascript/AJAX for pretty stuff.

However if these are all new to you, I would recommend looking at some of the Content Management Systems that are available out of the box. The ones I've come across are built on PHP/mySQL and can have a wealth of plugins and addons that can allow you to have a lot of advanced fuinctionality that might not be easy to do yourself. There are bundles of website templates available too, which can be customised relatively easily.

The main one I've worked with before is Joomla. That doesn't mean it's the ideal solution for what you're hoping to do, but something like this might cut down development times and costs (lots of plugins are free) immensely. And though it will present it's own learning curve, I didn't find it too bad. Drupal has also been recommended to me, but Joomla seemed much simpler to me at the time.

And Joomla installs real easily on a WAMP/LAMP setup.

I fully agree with this. Using CMSes is the way to get things done fast.

I run both Drupal and Joomla. Joomla is easier to start with but Drupal is kind of of more flexible, and as far as I have experienced it, and with all the respect to Joomla, the quality of the modules are better in Drupal. It should be said that I have more experience with Drupal.

They are both very good systems.

The talk about Ajax is kind of annoying, blown out of proportion, it is really nothing fancy at all. Ajax is just a technique where you from a JavaScript make a request to the server and you let the JavaScript take care of the response. You can then use the contents of the response for anything, but the normal way is to to update an existing tag with new content. The rest of the page is unaffected of this. It has been abound since ages and I used it 2003 first time to display changes in the status of machine in a production line. For me it is just another thing you can do with JavaScript and I don't understand why it deserves a name... I use it for man machine interfaces in the industry...

Having said that, you should use it if you need to update parts of you page.

But what you really should look at if you need pretty stuff is jQuery and jQueryUI. "Do more type less" or something like that is their slogan... You kind of make selections of your tags in you XHTML markup and apply changes to those tags. jQuery also have a very simple approach to Ajax... there is a 12 year old kid explaining jQuery on Youtube... listen to him after you updated your knowledge of XHTML/CSS.

PHP is the most common server scripting language. Quick for being scripting language.

Python and Ruby deserves to be mentioned and especially with the Ruby on Rails framework.

There are also PHP based Rails implementations. I used CakePHP for some project a few years ago. Sucked big time, but i guess it is better now.

Not all web hotels support Ruby on Rails... It is usually quite hungry for RAM...

I have never done anything serious with Ruby on Rails but I run a couple of servers at work with a ready made application that is built on Rails. (gitorious.org)

On the database server side, MySQL is dominating but there are others like Postgres... I have only used MySQL...

If you decide to go for a pure e-commerce solution I can recommend Os-Commerce. It was a few years since I used it but It was stable and had a lot of modules...

Martin

[RLM2008]

The talk about Ajax is kind of annoying, blown out of proportion, it is really nothing fancy at all. Ajax is just a technique where you from a JavaScript make a request to the server and you let the JavaScript take care of the response. You can then use the contents of the response for anything, but the normal way is to to update an existing tag with new content.

And if javascript is switched off? Just a thought.

Jquery's good but I wouldn't jump straight in. You need a decent grounding in javascript first and a good understanding of topics such as function contexts, variable scope, reference types, and closures.

For closures this is a very good article.

http://jibbering.com/faq/faq_notes/closures.html

The other thing to consider is how you plan to utilise jquery. In it's uncompressed format you're talking 4000+ lines of code, so if all you need is a couple of simple methods, it may be best just to roll your own.

If you're looking for books then here's a couple of links to check out

http://www.amsbook.com/modules/webs/frmSea...0853&TAB=10

http://bookweb.kinokuniya.co.jp/indexohb.c...A=07&LANG=E

To be honest if you need the site up and running quickly, it maybe best to just get someone else to do it. Learning this stuff isn't going to be a quick exercise, as I'm finding out:D

RLM

Edited February 15, 2010 by RLM2008

[RLM2008]

Ran out of edit time.

A few other things worthy of consideration.

Unobtrusive javascript. This also apply's to styling(CSS). You want to avoid inline styling and coding in your html.

A couple of quickly googled links.

http://www.alistapart.com/articles/behavioralseparation

http://en.wikipedia.org/wiki/Unobtrusive_JavaScript

Also worth looking into is web standards and semantic markup.

A book I recently bought from IT bookhouse covers this quite nicely

HTML and CSS Web Standard Solutions (Friends of ED publishers) ISBN 978-1-4302-1606-3

And finally it's worth pointing out that a lot of stuff that would have been done traditionally in javascript such as rollovers and drop down menus can be done more efficiently in CSS

http://buildinternet.com/2010/01/how-to-ma...e-powered-menu/

http://www.alistapart.com/articles/dropdowns/

Note: I'm only a novice myself, but thought I'd share a few key things I've picked up.

RLM

[welo]

The talk about Ajax is kind of annoying, blown out of proportion, it is really nothing fancy at all. Ajax is just a technique where you from a JavaScript make a request to the server and you let the JavaScript take care of the response. You can then use the contents of the response for anything, but the normal way is to to update an existing tag with new content. The rest of the page is unaffected of this. It has been abound since ages and I used it 2003 first time to display changes in the status of machine in a production line. For me it is just another thing you can do with JavaScript and I don't understand why it deserves a name... I use it for man machine interfaces in the industry...

Having said that, you should use it if you need to update parts of you page.

It is/was revolutionary since it allows to implement web-based applications that behave similar to a desktop UI (so called 'Rich Clients'). When just looking at traditional websites you will not see the full potential of Ajax, go checkout Google Documents and similar apps to understand why there is/was that much buzz around it. The concept of AJAX might be simple, but it fundamentally changed the way web applications (note: not web-sites) were built.

ExtJS is a well-known UI framework based on DHTML and AJAX, check out the samples page to get an idea what I'm talking about.

welo

[welo]

To the OP:

Sounds like typical requirements for a dynamic (database-driven) web application. Which way to go and what technologies to use will depend mostly on the 'features' (amount of automatism) you require and the effort (time and/or money) you want to put into the project.

If you have no experience with database-driven web development I do not recommend creating a solution from scratch (no matter which technology).

I'll try to give you a very brief overview of how web development changed over the years:

Starting with static HTML pages that resided as individual files on a web server those were later enriched with Javascript to allow some dynamic behavior on the client side. This part you probably know very well.

Then 'dynamic pages' came up where the content of the page was 'personalized' according to user input (form input or triggering actions by clicking certain links). This started off pretty basic with all information collected on a single form page and transferred to a special program running on the webserver (CGI) in a single request. The program would then do something (e.g. send an email, or query a data in a database on the server) and return a dynamically generated web page containing a message that the email has been successfully sent or the search result from the database as formatted HTML.

This limitation was overcome by session management (based on Cookies or URL rewriting) where multiple independent requests from the user where related to a single context/session, allowing to gather information over a series of web pages.

As server-side technologies evolved (competing technologies were Java, ASP, PHP) and the client side got kind of stuck due to MS winning the browser war leading to stagnation on the field of web browser development the focus shifted to the server-side. Most of the dynamic aspect was done on the server-side and doing client-side programming even became kind of 'bad' (as it was error prone and there were hardly any adequate tools to debug and maintain the code).

Websites grew to pretty complex processes such as online shops and online email applications, all still based on sending a request to the server which would then deliver the whole new page back to the browser, even if just parts of it have changed. The increase in line speed (broadband internet) and CPU power (both server for processing and client for rendering) supported this development.

However, the client-side grew stronger again with the upcoming and evolving of Flash and Javascript. The latter thanks to Firefox bringing fierce competition to IE and MS waking up (well, finally it occurred to them that internet was the 'future' and money to be made/lost). First those client-side technologies were hardly connected to the server-side (Flash started of as a simple plugin for graphical animations) but then developers came up with solutions how to access the personalized data stored on the server and finally AJAX combined with improved Javascript support (speed, tools, etc) brought the big breakthrough. The client-side programming got revived and as frameworks evolved and became more mature it was now possible to develop appliations with complex user interface (UI) logic that run within the browser and communicate with the server in the background, all based on Javascript, HTML and CSS. Flash is one competing technology that provides a complete framework for web browser based Rich Clients (google Flex). Of course it can still be used for graphical animations and stuff inside classical HTML based websites, (and is the number one solution to offer video support as we all know).

The confusing about the web development landscape nowadays is that modern application-like web based software co-exists with more traditional web-sites, and many solutions that are neither one nor the other. Just think about Facebook & Co, Flickr, Message Boards, Youtube etc. Many of those use a combination of page-centric architecture and Rich-Client technologies (AJAX, Flash).

Looking at your requirements I would tag your project still very 'traditional' since the focus seems to be on the content and the only non-content related features you need are a membership based user access control and some means of communication.

If you can limit your requirements to fit into the scope of a CMS then this would be a good way to go. However, be warned that a CMS usually can be customized only to a certain point, if your requirements go to far you might actually spend more time trying to get the software doing what you want than it originally saved you. The same applies to osCommerce and other eCommerce solutions. However, from what you mentioned so far a CMS seems suitable.

If you absolutely want to do it on your own, you can of course always keep it downright simple. Create rather static info pages around your products, use email (or email forms) for communication and setup a simple access control system linked to a user database where you manage your membership fees. Just be sure to hire a skilled web designer (if you are not one yourself) to give it a professional look.

If the project takes off you can invest more effort into a more automated (dynamic) system.

Some questions/ideas so you can get an idea about the difficult choice between what is POSSIBLE and what is NEEDED.

User Access Control

• Automated subscription process for a time-limited trial period (maybe limiting access to only parts of the products, parts of the information per product, etc)
  
• Automated payment process (credit-card)
  
• Automated payment reminder before end of membership
  
• Different payment/subscription models or classes of membership
  
• Combine with newsletter system to inform members and/or gain new memberships
  

Product Information

• What information is provided? Textual, Images, Videos, Data Sheets, File Downloads...
  
• Amount of products? Do you need Categories, Keywords, Product Search
  
• Who updates the information? Web developer vs. Company employees themselves.
  
• Promote products on start page ('Product of the month')
  

Communication Facililities

• Generate FAQ per product based on questions asked
  
• Communication 'inside' or 'outside' the system?
  
• 'Anonymous' communication without disclosure of company or customer details
  
• Live Chat System
  

Sorry if my answer is a bit over-the-top. I am curretnly in the process of getting back into that stuff, too, so your thread was a good opportunity for exercising my brain. Thanks for that

welo

[siamect]

The talk about Ajax is kind of annoying, blown out of proportion, it is really nothing fancy at all. Ajax is just a technique where you from a JavaScript make a request to the server and you let the JavaScript take care of the response. You can then use the contents of the response for anything, but the normal way is to to update an existing tag with new content. The rest of the page is unaffected of this. It has been abound since ages and I used it 2003 first time to display changes in the status of machine in a production line. For me it is just another thing you can do with JavaScript and I don't understand why it deserves a name... I use it for man machine interfaces in the industry...

Having said that, you should use it if you need to update parts of you page.

It is/was revolutionary since it allows to implement web-based applications that behave similar to a desktop UI (so called 'Rich Clients'). When just looking at traditional websites you will not see the full potential of Ajax, go checkout Google Documents and similar apps to understand why there is/was that much buzz around it. The concept of AJAX might be simple, but it fundamentally changed the way web applications (note: not web-sites) were built.

ExtJS is a well-known UI framework based on DHTML and AJAX, check out the samples page to get an idea what I'm talking about.

welo

The reason I think AJAX is blown out of proportion is that the word AJAX was invented about two years after I wrote my first application with HttpXMLRequest which was released I think 2002 in the Gecko engine. MS and Mozilla had done some development earlier than that. So when I first read about AJAX, I thought it was so yesterday... Just a new word for something everybody was already doing. At that time AJAX based applications was nothing special at all. They simply reacted quicker, without updating more than needed...

Later on, interesting things started to happen when people learned how to use CSS and the development of the JavaScript frame works like jQuery and ExtJS that you mentioned, matured. That gave the majority of programmers the ability to make all those dynamical things that you see on the desktop with very little code to write.

I think my first web based drag and drop application required me to write something like 800 rows of JavaScript where probably 600 was grabbed from someone else's project, just to get the drag and drop functionality. Now people do the same with maybe 100 rows or less...

Thanks for your posts. It is always interesting to get other peoples view of things...

Martin

[welo]

The reason I think AJAX is blown out of proportion is that the word AJAX was invented about two years after I wrote my first application with HttpXMLRequest which was released I think 2002 in the Gecko engine. MS and Mozilla had done some development earlier than that. So when I first read about AJAX, I thought it was so yesterday... Just a new word for something everybody was already doing. [..]

I can see your point and you're surely right about the term AJAX being introduced long after HttpXMLRequest appeared.

However, AJAX is much more than just the HttpXMLRequest, it is a term for a group of different technologies that allowed/enforced a paradigm shift in the concept of building dynamic websites and web applications. AJAX is actually a pretty fuzzy term and definitely not (only) technical - wikipedia writes that quote "the term 'Ajax' was coined in 2005 when Jesse James Garrett realized the need for a shorthand term to represent the suite of technologies he was proposing to a client."

I guess this is where your disliking for that term originates, and this is understandable. AJAX is definitely a term created to describe a whole bunch of things that already existed for quite some time before. Furthermore, it is not really a technology (e.g. a clearly defined protocol, API, etc) whereas the wording it stands for ('asynchronous Javascript and XML') kind of implies a standard or something. Well, it even goes so far as XML is not the preferred choice of encapsulating data anymore (but JSON is).

However, the main argument FOR using a term like AJAX IMHO is that it simplifies things and describes a concept that didn't have a name before and otherwise couldn't be described in less than 3 words.

And our discussion made me realize one interesting aspect about the 'history' of AJAX (and web development). Everything (meaning concepts, technologies, and actual real world code) was there for quite some time, but it was not until Google put on a major show case of AJAX in first Google Mail (2004) and then Google Maps (2005) that the whole IT community (including the decision makers) knew at once that AJAX (which didn't have a name yet) is not just some gimmick or toy but a serious technology ready for business. Sure there were others before (I remember being really impressed by Oddpost's commercial web UI framework - who were bought by Yahoo btw ) but Google was just so much bigger.

The two wikipedia articles on Ajax and Rich Internet Applications (RIA) are a good (brief) read on that topic, as well is the article 'a brief history of ajax'. To be honest I had to lookup a view things since I outsourced large parts of my memory to the internet a couple of years ago

welo