Web Based Technologies Question

[Ditto Much]

I’m looking at building a ‘car dealership’ website. What I would like would be a content management system hosting 10 – 20 dealerships all using a single data repository and server configuration. However I’m fairly flexible on this.

I’ve whipped off piles o sites in JSP/Struts/Hibernate but I can’t help but believe that this is over the top for my requirements.

Really the end use of the system is VERY simple. It’s a catalog of cars that can be sorted and searched. Its administration screens to add new cars and remove other cars as well as edit mistakes. Each car should be able to be displayed as a line item, or as n expanded view.

Is JSP/Struts/Hibernate a sledge hammer that isn’t worth its weight, should I be looking PHP.


Does anyone have any experience with Magnolia. I would prefer this being a content driven system with a meta data model rather than a flat table design. I don’t envision this being heavy traffic load but I would like to design a system that allows me to reuse the framework running multiple dealerships in parallel.

Any have any gut feelings on this?

 

[~atp~]

You could use a DB -> Hibernate -> SOAP -> XML/XSLT -> XHTML framework. I find that this sort of implementation carries enough abstraction to introduce portability without being an architectural monster.

 

[Sinister Shadow]

That said... I think it depends on your comfort level. PHP and Java (Struts) can accomplish similar things. If you're comfortable with Struts then do it that way. The fact that it's 10-20 dealerships means there is room to grow. Struts is very scaleable and if you do things right the back end will take care of itself.

Throw in a pre-made editing tool to do data updates and file uploads and you're rocking.

I think hibernate is a mistake. Using a real database is in order here for sure. MySQL?

In order to separate dealerships all I'd say you need is a user control on the system. Either uses (dealerships) have their own tables, or they can only access their data within parent tables. Some reading regarding user management and muti-access databases is probably in order so that you design the back end correctly.

If you want to learn something new... then dive into the PHP pool. However, the reality is their just different choices that do quite simmilar things.

Another one to look at perhaps is Spring. It's been an up an comming replacement for Struts for some time. It's more flexibile. That can be good or bad.

Unfortunately, I have no experience with Magnolia so can't comment.

 

[~atp~]

Originally posted by Sinister Shadow

I think hibernate is a mistake. Using a real database is in order here for sure. MySQL?

Hibernate isn't a database...

If you want to learn something new... then dive into the PHP pool. However, the reality is their just different choices that do quite simmilar things.

You can use PHP5 with SOAP clients and still leverage the power of hibernate. The advantage of this is the loose coupling between service layers from client to database (via XML).

 

[Ditto Much]

Originally posted by ~atp~
You could use a DB -> Hibernate -> SOAP -> XML/XSLT -> XHTML framework. I find that this sort of implementation carries enough abstraction to introduce portability without being an architectural monster.

What I would really like is a more canned sollution. I'd love to find a frame work that controls 'tiles' along with catlogs of products, has built in indexing and canned admin screens.

I'd rather use a CMS style arrangement as this allows me to offload managment of the site and saves me having to build the vast majority of administration screens.

I'd also like to be able to host multiple dealerships in an online 'car mall' fashion. Thus one super site that has n sub sites each of which have a different layout and owner and seperate content but all sharing the same database and the same web container and transaction engine.

Thus why I'm looking at Magnolia specifically..



The 'user' expereince is very limited in that they can't actually buy a single thing. Really they are all in read only mode and are stateless for the most part. My concern is in regards to the administration as these dealers will be constantly changing there inventory and prices and I'd rather make that as easy as possible.

I'm willing to sacrafice user experience for administration purposes.

 

[Sinister Shadow]

Originally posted by ~atp~
Hibernate isn't a database...
XML).

Right you are Ken.

My bad on this one...

Now I see... a persistence tool that maps objects to the database for you and eliminates the need to write SQL (aka manages your persistence objects for you).

Neato.

 

[Sinister Shadow]

I guess my tendancy would be to write something I could re-use rather than going with an open source system and building around it. But that's a pig headed approach that I know is a waste of effort.

There appear to be lots of CMS systems out there, open source, and retail. I again can't comment on them. I'd guess that spending a day with each and playing around with them would probably answer most of your questions. Maybe try 3 of them? 2 open source, one retail? See what works best for you after a few hours of fiddling.

That's a pretty obvious answer, but getting ones hands dirty almost always works.

 

[s-capade]

This site is really useful for comparing CMS features - http://www.cmsmatrix.org/

I have just gone through a round of looking at CMS systems, Magnolia I will say looks really promising however once you look at the licensing you will see that they have an open source version as well as a version you have to pay for, and the really good stuff is all in the pay version.

 

[~atp~]

I've deployed e107 on a few occasions, and find it ridiculously simple to use / customize. However, I'm not really sure that will fit the requirements here. I mean, if you want a pre-wrapped solution, I'd probably just flatten all your middleware crap into a PHP -> ADODB -> MySQL thing...

 

[Liquidity]

sounds like something you could do with XML/XSLT...

how much content management are you talking here? daily? weekly? monthly?