Approach for a content heavy website

[YoJimbo]

Hello

We have had great experience building a comet heavy "single page" type
web application - at recent product demos we have had comments that
the product is the best thing people have seen in our vertical market,
and a lot of credit for that is firmly on the lift community.
We are now moving into a long development cycle, but our focus is
starting to switch from an developing a single page web application
like google reader or gmail to a content heavy B2C website more like
ESPN or the BBC.

This means that instead of presenting real time data, we need to think
more in terms of content management, content rotation - yet still have
the ability to mix in the comet heavy technology.

I guess a prime example would be a site like -

http://www.marketwatch.com/markets

Here we see news articles and (what could be) comet updated data on
the same page. The markets data will be coming through a completely
different route through the business than news articles - so on one
side you have creative writing work flow, approval and scheduling but
on another you have hard data coming from third party feeds or market
traders inputting data.
We are getting very good a managing the data side of things but
content management is new.

-----------

How would you guys approach this kind of project? Some thoughts -

LIft fronting a CMIS or JCR repository so Alfresco or Jackrabbit
LIft with something like Drupal and or OpenX
Doing everything in Lift
A another option

Any ideas or insights?

[TylerWeir]

I'd leverage the knowledge you've built up creating the single-page app and build the CMS style app.

I'm assuming you'll be pretty quick.

And take a look at Hoisted - https://github.com/dpp/hoisted

[David Pollak]

I'd do everything in Lift, but I'm biased. ;-)

The Guardian (http://guardian.co.uk) is moving to Lift for their content management system, so it's pretty evident that Lift provides a reasonable platform for presenting complex content.

The pieces that I see are:

• The data store and manipulating content in that data store.  I'd choose MongoDB for a back end.  Everyone I've spoken with has glowing things to say about MongoDB and given the support 10Gen gives generically and Lift related, they're super-stars in my book.  You'll need to write some sort of front-end to the DB for content creation/editing.  This front end is non-trivial and has always been the stumbling block for me to do a form CMS in Lift.
• Then there's the rendering piece.  The rendering piece is pure Lift.  If you don't need to mix Comet with the CMS, you can take a look at hoisted as Tyler pointed out.  It's a reason basis for a CMS.  Currently, it looks for documents on the file system, but could easily look in MongoDB as well.  For updates, you could do Ajax polling every 5 seconds or so.  That would remove the need for session affinity which would give you a little more flexibility for rolling software updates.
• If you decide that you need Comet (for example if you're doing stuff where 5 seconds really makes a difference like a stock ticker), you'll have to do a bunch of stuff with URL rewrites so that requests get forwarded to what is in effect a single page that contains the "look up the content based on URL" snippet.

Hope this helps... if you've got specific questions, please let me know and I'll do my best to answer them.

Thanks,

David
 

A another option

Any ideas or insights?

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

--
Lift, the simply functional web framework http://liftweb.net

Simply Lift http://simply.liftweb.net
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

[YoJimbo]

Posting an update on this thread with our findings.
Being a small development company and content management is important
to our business - but does not directly make us money.
So before developing our own solution we have spent a few days
reviewing the options out there for enterprise content management in
the opensource and commercial opensource space.

We started off with the concept - can we take an off the shelf content
management application and use it as an intelligent content store.
When people say CMS usually they are speaking about: Drupal, Wordpress
etc
We want to do most of what these CMS do in Lift.
So our aim was to find a repository for our content that does not
expect to be serving up pages directly - taking Drupal, Wordpress and
all the other solutions off the table.

So we could have a lift app making requests for:

foo.jpg for www.mysite.com
foo.jpg where the meta-information listed this as the live version
foo.jpg the last but one version in the revision history
Or all all images created between 01-Dec and the 25th of December
where the meta information was Christmas

Via one of the open standards to do this - CMIS or JCR or other remote
way

We reviewed Alfresco and Nuxeo with the aim of doing little
development spikes.
They advertise that this is what their content management apps are
designed to do , with the added benefit of having workflows, security,
clustering and all the good stuff.
The theory to us sounded perfect for what we wanted.

We cut short the effort (in disgust).

Lots of documentation aimed at administering their application - but
very little practical documentation about how to accomplish basic
tasks from a development standpoint
Books that just rewrite the documentation on administering the
application
Very weak communities, because this goes against the companies model
of providing profesional services. The alfresco forum in particular
has lots of people asking questions or for help and nobody answering -
or the classic of someone posting "never mind I found the answer
myself" with no details.
Products limited by the standards they are advertising - want to use
JSON... oh no thats not part of CMIS 1.0 you will have to wait for
CMIS 1.1 and then at some point in the future our product will adopt
some or all of that spec.
Also it was clear we would have to write our own caching layer, as the
performance of some of the basic tests we want was worrying.

So we will prioritize our need for a CMS and look into David's
recommendations.



On Jul 5, 1:42 pm, David Pollak <feeder.of.the.be...@gmail.com> wrote:

>    - The data store and manipulating content in that data store.  I'd choose

>    MongoDB for a back end.  Everyone I've spoken with has glowing things to say
>    about MongoDB and given the support 10Gen gives generically and Lift
>    related, they're super-stars in my book.  You'll need to write some sort of
>    front-end to the DB for content creation/editing.  This front end is
>    non-trivial and has always been the stumbling block for me to do a form CMS
>    in Lift.

>    - Then there's the rendering piece.  The rendering piece is pure Lift.

>    If you don't need to mix Comet with the CMS, you can take a look at hoisted
>    as Tyler pointed out.  It's a reason basis for a CMS.  Currently, it looks
>    for documents on the file system, but could easily look in MongoDB as well.
>    For updates, you could do Ajax polling every 5 seconds or so.  That would
>    remove the need for session affinity which would give you a little more
>    flexibility for rolling software updates.

>    - If you decide that you need Comet (for example if you're doing stuff

>    where 5 seconds really makes a difference like a stock ticker), you'll have
>    to do a bunch of stuff with URL rewrites so that requests get forwarded to
>    what is in effect a single page that contains the "look up the content based
>    on URL" snippet.
>
> Hope this helps... if you've got specific questions, please let me know and
> I'll do my best to answer them.
>
> Thanks,
>
> David
>
> > A another option
>
> > Any ideas or insights?
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Lift" group.
> > To post to this group, send email to lif...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > liftweb+u...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/liftweb?hl=en.
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net

> Simply Lifthttp://simply.liftweb.net