A Lift CMS module
120 views
Skip to first unread message
David Pollak
Aug 17, 2010, 1:49:01 PM8/17/10
to liftweb
Folks,
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics
I've been working on a light-weight set of CMS code for Lift (yep, the next version of the LiftWeb.net site will be deployed on this).
I'm noodling with either making it a Lift module or alternatively making it a separate project.
As a Lift module, it'll be compiled along with normal Lift releases. But it also means that the API will get frozen more quickly.
As a stand-alone project, there will be much more of a chance for API evolution. The problem is the complexity of building against Scala 2.7.7, 2.8.0, 2.8.1, etc. and Lift 2.1, 2.2, 3.0, etc.
What do folks think?
Is there a way to designate parts of Lift that have evolving APIs such that the 2.x line is source compatible except for modules marked as "evolving"?
Thanks,
David
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics
Timothy Perrett
Aug 17, 2010, 1:58:33 PM8/17/10
to lif...@googlegroups.com
Sounds super.
Ok, so I think it depends on how much integration you need / want with Lift itself. I don't see a huge benefit (if any) to it being in Lift core.
In fact, I actually wouldn't mind seeing the main lift repo being broken out into other repositories within our github organisation. To that end, I think you could have it as a separate project but still within the Lift organisation which would give it the "offical lift" status, but not polluting the core project and suffering from frozen APIs.
WDYT?
Cheers, Tim
> --
> 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.
David Pollak
Aug 17, 2010, 2:02:24 PM8/17/10
to lif...@googlegroups.com
On Tue, Aug 17, 2010 at 10:58 AM, Timothy Perrett <tim...@getintheloop.eu> wrote:
Sounds super.
Ok, so I think it depends on how much integration you need / want with Lift itself. I don't see a huge benefit (if any) to it being in Lift core.
In fact, I actually wouldn't mind seeing the main lift repo being broken out into other repositories within our github organisation. To that end, I think you could have it as a separate project but still within the Lift organisation which would give it the "offical lift" status, but not polluting the core project and suffering from frozen APIs.
WDYT?
Integrating the module with the Lift build process is the critical factor from my perspective so the code is spit out with SNAPSHOT, Milestone and release builds.
Timothy Perrett
Aug 17, 2010, 2:08:41 PM8/17/10
to lif...@googlegroups.com
So it sounds like you only have one route forward that will satisfy this :-)
Wade Arnold
Aug 17, 2010, 6:07:02 PM8/17/10
to Lift
I would be interested in working on using lifts state machine in order
to do some workflows for approvals. Another fun concept would be to do
a scheduler for putting content into the future. Plugins are critical
for CMS tools and those should probably be hosted outside of lift
project.
I am interested to know your thoughts on if you have to break any of
the security strengths of Lift by creating pages dynamically.
I would love to help!
Wade
On Aug 17, 12:49 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:
to do some workflows for approvals. Another fun concept would be to do
a scheduler for putting content into the future. Plugins are critical
for CMS tools and those should probably be hosted outside of lift
project.
I am interested to know your thoughts on if you have to break any of
the security strengths of Lift by creating pages dynamically.
I would love to help!
Wade
On Aug 17, 12:49 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:
> Folks,
>
> I've been working on a light-weight set of CMS code for Lift (yep, the next
> version of the LiftWeb.net site will be deployed on this).
>
> I'm noodling with either making it a Lift module or alternatively making it
> a separate project.
>
> As a Lift module, it'll be compiled along with normal Lift releases. But it
> also means that the API will get frozen more quickly.
>
> As a stand-alone project, there will be much more of a chance for API
> evolution. The problem is the complexity of building against Scala 2.7.7,
> 2.8.0, 2.8.1, etc. and Lift 2.1, 2.2, 3.0, etc.
>
> What do folks think?
>
> Is there a way to designate parts of Lift that have evolving APIs such that
> the 2.x line is source compatible except for modules marked as "evolving"?
>
> Thanks,
>
> David
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://www.apress.com/book/view/1430219890
>
> I've been working on a light-weight set of CMS code for Lift (yep, the next
> version of the LiftWeb.net site will be deployed on this).
>
> I'm noodling with either making it a Lift module or alternatively making it
> a separate project.
>
> As a Lift module, it'll be compiled along with normal Lift releases. But it
> also means that the API will get frozen more quickly.
>
> As a stand-alone project, there will be much more of a chance for API
> evolution. The problem is the complexity of building against Scala 2.7.7,
> 2.8.0, 2.8.1, etc. and Lift 2.1, 2.2, 3.0, etc.
>
> What do folks think?
>
> Is there a way to designate parts of Lift that have evolving APIs such that
> the 2.x line is source compatible except for modules marked as "evolving"?
>
> Thanks,
>
> David
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
David Pollak
Aug 17, 2010, 6:20:20 PM8/17/10
to lif...@googlegroups.com
On Tue, Aug 17, 2010 at 3:07 PM, Wade Arnold <wade....@t8design.com> wrote:
I would be interested in working on using lifts state machine in order
to do some workflows for approvals.
The "Machine" module needs a lot of love. It is a 3+ year old module that was only used in one project that I know of. It'd be great to update it to make it back-end neutral.
I'm not sure how much of the approval stuff I'll put into the code initially. My goal is to have something that can host the liftweb.net site.
Another fun concept would be to do
a scheduler for putting content into the future.
That'll be built in.
Plugins are critical
for CMS tools and those should probably be hosted outside of lift
project.
Rather than writing a CMS, I'm going to write some abstractions. I will do some example code that demonstrates the CMS, but my goal is not to write a CMS, but to give folks tools for integrating CMS-like functionality into their sites.
I am interested to know your thoughts on if you have to break any of
the security strengths of Lift by creating pages dynamically.
Yes. Security is very important. There will be different security levels. Some people will be able to define content with any snippets, where others will only be able to access certain snippets.
I would love to help!
Please point me to the major features you would like to see in a CMS... that's the best place to start helping.
Wade
On Aug 17, 12:49 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:
> Folks,> Beginning Scalahttp://www.apress.com/book/view/1430219890
>
> I've been working on a light-weight set of CMS code for Lift (yep, the next
> version of the LiftWeb.net site will be deployed on this).
>
> I'm noodling with either making it a Lift module or alternatively making it
> a separate project.
>
> As a Lift module, it'll be compiled along with normal Lift releases. But it
> also means that the API will get frozen more quickly.
>
> As a stand-alone project, there will be much more of a chance for API
> evolution. The problem is the complexity of building against Scala 2.7.7,
> 2.8.0, 2.8.1, etc. and Lift 2.1, 2.2, 3.0, etc.
>
> What do folks think?
>
> Is there a way to designate parts of Lift that have evolving APIs such that
> the 2.x line is source compatible except for modules marked as "evolving"?
>
> Thanks,
>
> David
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
--
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
Beginning Scala http://www.apress.com/book/view/1430219890Timothy Perrett
Aug 17, 2010, 6:42:03 PM8/17/10
to lif...@googlegroups.com
Interesting.
What feature abstractions are on your list thus far?
Cheers, Tim
David Pollak
Aug 17, 2010, 7:50:14 PM8/17/10
to lif...@googlegroups.com
On Tue, Aug 17, 2010 at 3:42 PM, Timothy Perrett <tim...@getintheloop.eu> wrote:
Interesting.
What feature abstractions are on your list thus far?
I've been looking at doing everything as Types/Type Contructors/Functions on Constructed Types + Pattern Matching. This way, we don't need to specify a specific type of user or content holder or anything like that...
Cheers, Tim
On 17 Aug 2010, at 23:20, David Pollak wrote:
> Rather than writing a CMS, I'm going to write some abstractions. I will do some example code that demonstrates the CMS, but my goal is not to write a CMS, but to give folks tools for integrating CMS-like functionality into their sites.
--
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.
Chaba
Aug 17, 2010, 8:54:46 PM8/17/10
to Lift
I think having a stand alone bigger application would really benefit
Lift.
Several reasons:
- It would help with the documentation. Before "how do I ..."
questions you just look it up in the CMS code.
- Soon people will have requests, like Mediawiki syntax and access
rights. They will even implement it, so the whole project might grow
really big (hopefully).
- Also it would help the Lift maintainers understand the issues
mortals have, ex. keeping up with Scala and Lift versions, especially
when they are removed from the repo.
- I think it still can be built automatically like Lift, but the
lifecycle would differ, which is a good thing.
My 2 cents.
Chaba
On Aug 17, 4:50 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:
> > .
Lift.
Several reasons:
- It would help with the documentation. Before "how do I ..."
questions you just look it up in the CMS code.
- Soon people will have requests, like Mediawiki syntax and access
rights. They will even implement it, so the whole project might grow
really big (hopefully).
- Also it would help the Lift maintainers understand the issues
mortals have, ex. keeping up with Scala and Lift versions, especially
when they are removed from the repo.
- I think it still can be built automatically like Lift, but the
lifecycle would differ, which is a good thing.
My 2 cents.
Chaba
On Aug 17, 4:50 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:
> On Tue, Aug 17, 2010 at 3:42 PM, Timothy Perrett <timo...@getintheloop.eu>wrote:
>
> > Interesting.
>
> > What feature abstractions are on your list thus far?
>
> I've been looking at doing everything as Types/Type Contructors/Functions on
> Constructed Types + Pattern Matching. This way, we don't need to specify a
> specific type of user or content holder or anything like that...
>
>
>
>
>
>
>
> > Cheers, Tim
>
> > On 17 Aug 2010, at 23:20, David Pollak wrote:
>
> > > Rather than writing a CMS, I'm going to write some abstractions. I will
> > do some example code that demonstrates the CMS, but my goal is not to write
> > a CMS, but to give folks tools for integrating CMS-like functionality into
> > their sites.
>
> > --
> > 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<liftweb%2Bunsu...@googlegroups.com >
>
> > Interesting.
>
> > What feature abstractions are on your list thus far?
>
> I've been looking at doing everything as Types/Type Contructors/Functions on
> Constructed Types + Pattern Matching. This way, we don't need to specify a
> specific type of user or content holder or anything like that...
>
>
>
>
>
>
>
> > Cheers, Tim
>
> > On 17 Aug 2010, at 23:20, David Pollak wrote:
>
> > > Rather than writing a CMS, I'm going to write some abstractions. I will
> > do some example code that demonstrates the CMS, but my goal is not to write
> > a CMS, but to give folks tools for integrating CMS-like functionality into
> > their sites.
>
> > --
> > 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
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/liftweb?hl=en.
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://www.apress.com/book/view/1430219890
> >http://groups.google.com/group/liftweb?hl=en.
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
XiaomingZheng
Aug 26, 2010, 4:20:44 AM8/26/10
to Lift
exciting new! when first version come?
On 8月18日, 上午1时58分, Timothy Perrett <timo...@getintheloop.eu> wrote:
> Sounds super.
>
> Ok, so I think it depends on how much integration you need / want with Lift itself. I don't see a huge benefit (if any) to it being in Lift core.
>
> In fact, I actually wouldn't mind seeing the main lift repo being broken out into other repositories within our github organisation. To that end, I think you could have it as a separate project but still within the Lift organisation which would give it the "offical lift" status, but not polluting the core project and suffering from frozen APIs.
>
> WDYT?
>
> Cheers, Tim
>
> On 17 Aug 2010, at 18:49, David Pollak wrote:
>
>
>
> > Folks,
>
> > I've been working on a light-weight set ofCMScode for Lift (yep, the next version of the LiftWeb.net site will be deployed on this).
On 8月18日, 上午1时58分, Timothy Perrett <timo...@getintheloop.eu> wrote:
> Sounds super.
>
> Ok, so I think it depends on how much integration you need / want with Lift itself. I don't see a huge benefit (if any) to it being in Lift core.
>
> In fact, I actually wouldn't mind seeing the main lift repo being broken out into other repositories within our github organisation. To that end, I think you could have it as a separate project but still within the Lift organisation which would give it the "offical lift" status, but not polluting the core project and suffering from frozen APIs.
>
> WDYT?
>
> Cheers, Tim
>
> On 17 Aug 2010, at 18:49, David Pollak wrote:
>
>
>
> > Folks,
>
>
> > I'm noodling with either making it a Lift module or alternatively making it a separate project.
>
> > As a Lift module, it'll be compiled along with normal Lift releases. But it also means that the API will get frozen more quickly.
>
> > As a stand-alone project, there will be much more of a chance for API evolution. The problem is the complexity of building against Scala 2.7.7, 2.8.0, 2.8.1, etc. and Lift 2.1, 2.2, 3.0, etc.
>
> > What do folks think?
>
> > Is there a way to designate parts of Lift that have evolving APIs such that the 2.x line is source compatible except for modules marked as "evolving"?
>
> > Thanks,
>
> > David
>
> > --
> > Lift, the simply functional web frameworkhttp://liftweb.net
> > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > I'm noodling with either making it a Lift module or alternatively making it a separate project.
>
> > As a Lift module, it'll be compiled along with normal Lift releases. But it also means that the API will get frozen more quickly.
>
> > As a stand-alone project, there will be much more of a chance for API evolution. The problem is the complexity of building against Scala 2.7.7, 2.8.0, 2.8.1, etc. and Lift 2.1, 2.2, 3.0, etc.
>
> > What do folks think?
>
> > Is there a way to designate parts of Lift that have evolving APIs such that the 2.x line is source compatible except for modules marked as "evolving"?
>
> > Thanks,
>
> > David
>
> > --
> > Lift, the simply functional web frameworkhttp://liftweb.net
David Pollak
Aug 26, 2010, 2:37:58 PM8/26/10
to lif...@googlegroups.com
On Thu, Aug 26, 2010 at 1:20 AM, XiaomingZheng <xiaomin...@gmail.com> wrote:
exciting new! when first version come?
Dunno. Hopefully next week (but it will be in a fork during the Lift code slush)
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890Wade Arnold
Aug 31, 2010, 6:48:22 PM8/31/10
to Lift
Ok these are the types of features that I am interested in working on
in a lift based CMS system.
Ideally this would be WYSIWYG with dom manipulation. I can help
probably the most from the jquery standpoint or just build on top of
what you are creating.
Edit the LiftRules sitemap of the website and add hierarchy to the
navigation.
Edit the template that each page is presented with based on a list of
available surrounds.
Upload images and other web resources into Document management system
- ability to tag files
- ability to resize images, REST server.
- image repository for reuse across site.
Different output formats such as XHTML, Mobil, RSS/ATOM, JSON
Internal apache lucene search
ability to add tags to sections so that topics could be related.
Allow for multiple languages
Add external content into an embed which could be reused in the
template
User level access control to update different templates based on user
roles. Utilizing the existing LDAP support would be nice.
Automatic Google sitemap module
Forms creator for the wizard.
URL Schema is something that needs to be configurable. Every three
weeks the SEO wizards have a new schema that was handed down to them
from some conference that the CMS system must now follow.
Workflow for approval process
If it is not essential for every website make it an extension. Its
core needs to be designed to allow extension developers to easily
access and manipulate the front and backend.
Hope that helps?!?
Wade
On Aug 17, 5:20 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:
> > liftweb+u...@googlegroups.com<liftweb%2Bunsu...@googlegroups.com >
> > .
in a lift based CMS system.
Ideally this would be WYSIWYG with dom manipulation. I can help
probably the most from the jquery standpoint or just build on top of
what you are creating.
Edit the LiftRules sitemap of the website and add hierarchy to the
navigation.
Edit the template that each page is presented with based on a list of
available surrounds.
Upload images and other web resources into Document management system
- ability to tag files
- ability to resize images, REST server.
- image repository for reuse across site.
Different output formats such as XHTML, Mobil, RSS/ATOM, JSON
Internal apache lucene search
ability to add tags to sections so that topics could be related.
Allow for multiple languages
Add external content into an embed which could be reused in the
template
User level access control to update different templates based on user
roles. Utilizing the existing LDAP support would be nice.
Automatic Google sitemap module
Forms creator for the wizard.
URL Schema is something that needs to be configurable. Every three
weeks the SEO wizards have a new schema that was handed down to them
from some conference that the CMS system must now follow.
Workflow for approval process
If it is not essential for every website make it an extension. Its
core needs to be designed to allow extension developers to easily
access and manipulate the front and backend.
Hope that helps?!?
Wade
On Aug 17, 5:20 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:
> > .
Reply all
Reply to author
Forward
0 new messages