Problem building from source

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Hippo 6 vs Hippo 7

JunNi

Hi all,

I am a Hippo 6 user and I am evaluating Hippo 7. I understand that Hippo 7 is completely re-written based on different technologies. However, I can’t stop having questions when comparing the two.

 

So here they are:

1. Repository

  a. The new repository is based on JCR. Seems that it comes with the CMS pre-built package (I haven’t try building from scratch yet) rather than two packages one for cms and one for repository. So my first question is, can I run the repository on a different server? What about clustering?

  b. In Hippo 6, I was able to view the file content via http in the xml format I defined. Can I do that in Hippo 7? I know I can get to the file contents at http://localhost:8080/cms/repository/content, but it’s no longer a simple xml that I can just take and use? Are the contents now stored in different formats in Hippo 7?

  c. What about webdav access to the repository?

  d. Hippo 6 used OpenJMS to broadcast messages. We were able to tap into the ojms and receive updates from it as a work around for making slow dasl queries for the recent updates. Do we have something similar in Hippo 7? Or were the performance issue in Hippo 6 already being addressed, such that we don’t need to do this kind of workaround anymore? Are there alternatives?

 

2. Document type

  a. In Hippo 6, I can define the xml format of each document type. In Hippo 7, it seems that I can only define the caption of each widget, but what is the underlying data format?

  b. Hippo 6 had a lot of cool widgets, but we only seem to have a handful of them in Hippo 7. Do you have plans to add more widgets in?

  c. Hippo 6 uses Xinha as the rich text editor. It’s an older version with some issues, but it had the functionalities we wanted. What does Hippo 7 uses? The rich text editor seems to have only limited functionalities (btw, I looked into the Rich Text Editor config email thread, and got completely lost there). To be specific, the issue we are trying to address was clearing up MS Word specific tags properly upon paste. We know that the older Xinha can’t do a good job, and it can’t interpret the bullets and numbered list well. I tested the new Xinha and it seems to do the job. Hippo 7’s rich text editor still has that problem though, so that was a disappointment to me.

  d. In Hippo 6 I can specify the preview urls, as well as limiting document types in per directory bases. Can I do that in Hippo 7? (actually, where is preview in Hippo 7?)

 

3. Data migration

  a. how difficult would it be for us to migrate existing data and document type definitions to hippo 7? We are talking about 30k+ documents here.

 

That’s just a starter for all my questions on Hippo 7. I would really appreciate it if someone could help me find my way around in Hippo 7.

 

Thanks!

Jun

 


_______________________________________________
Hippo-cms7-user mailing list and forums
http://www.onehippo.org/cms7/support/community.html
Reply | Threaded
Open this post in threaded view
|

Re: Hippo 6 vs Hippo 7

David Legg
Hi Jun,

> I am a Hippo 6 user and I am evaluating Hippo 7. I understand that
> Hippo 7 is completely re-written based on different technologies.
> However, I can’t stop having questions when comparing the two.
>

I'm in the same situation as you except I was just learning about Hippo
6 when Hippo 7 was announced. I'm not an expert but I thought I'd give
you my take on things so far. Unfortunately, you replied to someone
else's already long message thread which is probably one reason why
nobody else has responded so far. If you have an unrelated question it
is usually better to create a brand new message to the list than reply
to someone else's.

> a. The new repository is based on JCR. Seems that it comes with the
> CMS pre-built package (I haven’t try building from scratch yet) rather
> than two packages one for cms and one for repository. So my first
> question is, can I run the repository on a different server? What
> about clustering?
>

This is an understatement! When I first heard of CMS7 I thought it would
just be a bigger, faster, better version of CMS6. It turns out it is a
completely different animal altogether. I'm only considering it because
I have no existing CMS6 content to port to it unlike you. CMS7 is still
in early Alpha and although I get the impression Hippo have used it in
some installations I think it will be a few months before the likes of
you or I could risk it.

Running the CMS and the repository separately is on the roadmap as far
as I can see. The ability to import CMS6 content to CMS7 is also
something that is on the cards but not available right now.

> b. In Hippo 6, I was able to view the file content via http in the xml
> format I defined. Can I do that in Hippo 7? I know I can get to the
> file contents at http://localhost:8080/cms/repository/content, but
> it’s no longer a simple xml that I can just take and use? Are the
> contents now stored in different formats in Hippo 7?
>

I'm also interested in the answer to this. My guess is that since CMS7
is based on JCR section 6.4 'XML Mappings' should hold true. This means
that it should be possible to use the standard JCR functionality to
export the entire repository as XML which can then be imported by
another JCR installation without loss of information. The JCR api seems
to define a schema (with namespace = "http://www.jcp.org/jcr/sv/1.0")
for this which would allow you to get back bits of the repository tree
as XML. You would have to perform some transformations on this if you
needed it to be compatible with your old XML format.

> c. What about webdav access to the repository?
>

I have already asked about this and the answer seems to be that Webdav
is too slow and RMI is the preferred way to access the repository.
However, it seems that accessing the native JCR api through RMI is also
too slow and the trunk version of CMS7 is now using JackRabbit's SPI api
through RMI.

> 2. Document type
>
> a. In Hippo 6, I can define the xml format of each document type. In
> Hippo 7, it seems that I can only define the caption of each widget,
> but what is the underlying data format?
>

I guess the answer to this is somewhere in the as yet unreleased HST2
code. However, more generally, I think the best approach is to think in
terms of what structure will be created in the repository. In other
words what nodes and/or properties get created.

> b. Hippo 6 had a lot of cool widgets, but we only seem to have a
> handful of them in Hippo 7. Do you have plans to add more widgets in?
>

I'm sure they do. It's early days yet. Hippo have gone to a lot of
trouble to define the concept of 'addons'. These are things that we can
make ourselves if need be or get from the Hippo web site and simply
extend the Repository or CMS in any way we wish. Indeed the first 25
people to writean interesting addon will get a Hippo T-Shirt!

> c. Hippo 6 uses Xinha as the rich text editor. It’s an older version
> with some issues, but it had the functionalities we wanted. What does
> Hippo 7 uses? The rich text editor seems to have only limited
> functionalities (btw, I looked into the Rich Text Editor config email
> thread, and got completely lost there).
>

CMS7 can use Xinha too. Not sure what version it is. Don't worry about
the apparent limited functionality. It is possible to turn bits on and
off as required and that was why I asked the question in that email thread.

> d. In Hippo 6 I can specify the preview urls, as well as limiting
> document types in per directory bases. Can I do that in Hippo 7?
> (actually, where is preview in Hippo 7?)
>

This is actually one of HREPTWO's more interesting features. It is
possible to to create whole trees of virtual repository nodes depending
on the properties of an existing node. Out of the box the quickstart
demo creates a 'live' and a 'preview' tree based on those nodes in the
content tree which have a certain value in hippostd:state property. This
is one of the benefits of the new extended support for facets in the
repository. So for example if the CMS changes the property of a node
from preview to live it will automatically become visible in the live
tree when you next access the repository.

> 3. Data migration
>
> a. how difficult would it be for us to migrate existing data and
> document type definitions to hippo 7? We are talking about 30k+
> documents here.
>

I can't help here... except to say adding the necessary tools is on the
roadmap.

> That’s just a starter for all my questions on Hippo 7. I would really
> appreciate it if someone could help me find my way around in Hippo 7.
>
Glad to help.
Regards,

David Legg

_______________________________________________
Hippo-cms7-user mailing list and forums
http://www.onehippo.org/cms7/support/community.html
Reply | Threaded
Open this post in threaded view
|

Re: Hippo 6 vs Hippo 7

David Legg
I forgot to add a reference to the JCR API guide.

>> b. In Hippo 6, I was able to view the file content via http in the
>> xml format I defined. Can I do that in Hippo 7? I know I can get to
>> the file contents at http://localhost:8080/cms/repository/content,
>> but it’s no longer a simple xml that I can just take and use? Are the
>> contents now stored in different formats in Hippo 7?
>
> I'm also interested in the answer to this. My guess is that since CMS7
> is based on JCR section 6.4 'XML Mappings' should hold true.

I'm referring to section 6.4 of the Java Specification Request 170.  
This is a very useful document which covers all the fundamental aspects
of content repositories.  You would do well to read it before tackling
the Hippo documentation.

Unfortunately, I think Sun have rather stupidly placed the document
behind a 'corporate' site which might put some people off downloading
it.  Anyway here's the URL... http://jcp.org/en/jsr/detail?id=170 just
click on the latest release link titled 'Download page' tick the box to
sign your life away, press continue and then click on the link for the
zip file of the spec.  Unzip the file once downloaded and your done...
nearly ;-)

Regards,
David Legg

_______________________________________________
Hippo-cms7-user mailing list and forums
http://www.onehippo.org/cms7/support/community.html
Reply | Threaded
Open this post in threaded view
|

Re: Hippo 6 vs Hippo 7

Arje Cahn
Administrator
In reply to this post by David Legg
Hi Jun, David,

Allow me to jump in  :-)

> Running the CMS and the repository separately is on the roadmap as far as I
> can see. The ability to import CMS6 content to CMS7 is also something that
> is on the cards but not available right now.

Yes, we will be splitting the CMS and the Repository just like we did
in Hippo CMS 6.
Technically speaking, they are already separated but there's a
performance hit when you run them separated that we want to have
resolved first. That's one of the things we're currently working on
(Jackrabbit's SPI api). This is the issue you'll want to monitor:
http://issues.onehippo.org/browse/HREPTWO-2055

>> b. In Hippo 6, I was able to view the file content via http in the xml
>> format I defined. Can I do that in Hippo 7? I know I can get to the file
>> contents at http://localhost:8080/cms/repository/content, but it’s no longer
>> a simple xml that I can just take and use? Are the contents now stored in
>> different formats in Hippo 7?
>
> I'm also interested in the answer to this. My guess is that since CMS7 is
> based on JCR section 6.4 'XML Mappings' should hold true. This means that it
> should be possible to use the standard JCR functionality to export the
> entire repository as XML which can then be imported by another JCR
> installation without loss of information.

Yes :)
The console actually exposes this functionality
(http://localhost:8080/cms/console). But that's not really the HTTP
interface you're looking for.

We're also discussing CMIS, Atom, REST, etc. Not decided which way to
go yet, but having an HTTP interface to the Repository is definitely
something worthwhile to have. For now, we're focusing on Java
interfacing using the JCR. Adding an HTTP layer on top should not be a
big deal, but we need some way of mapping nodes in the Repository to
XML structures in a standardized way.

>> c. What about webdav access to the repository?
>
> I have already asked about this and the answer seems to be that Webdav is
> too slow

Sorry, that must be a misunderstanding.. Of course, WebDAV has its
uses - especially when storing content across a network. But when
you're using Java, talking to the JCR directly is obviously the way to
go. It also allows for a much better caching strategy too (see SPI
layer).

You could take a look at the Jackrabbit WebDAV Library:
http://jackrabbit.apache.org/jackrabbit-webdav-library.html

> However, it
> seems that accessing the native JCR api through RMI is also too slow and the
> trunk version of CMS7 is now using JackRabbit's SPI api through RMI.

That's correct. The SPI layer will fix a lot of performance and
caching issues. Also improves clustering.

>> b. Hippo 6 had a lot of cool widgets, but we only seem to have a handful
>> of them in Hippo 7. Do you have plans to add more widgets in?
>
> I'm sure they do.

Yes we do :)
Our focus is to give you a plugin framework with lots and lots of
plugins (widgets/addons/etc). We're providing a forge installation on
http://forge.onehippo.org, where everyone can host their own plugins
(aka widgets). This is where all the action will be!

> It's early days yet. Hippo have gone to a lot of trouble
> to define the concept of 'addons'. These are things that we can make
> ourselves if need be or get from the Hippo web site and simply extend the
> Repository or CMS in any way we wish. Indeed the first 25 people to writean
> interesting addon will get a Hippo T-Shirt!

What are you waiting for, David!! :-D

>> c. Hippo 6 uses Xinha as the rich text editor. It’s an older version with
>> some issues, but it had the functionalities we wanted. What does Hippo 7
>> uses? The rich text editor seems to have only limited functionalities (btw,
>> I looked into the Rich Text Editor config email thread, and got completely
>> lost there).
>
> CMS7 can use Xinha too. Not sure what version it is. Don't worry about the
> apparent limited functionality. It is possible to turn bits on and off as
> required and that was why I asked the question in that email thread.

I think I can pretty much stop answering questions since you seem to
cover all of them David ... ;)
But you're correct. We're providing a very barebones Xinha plugin,
with the intention of adding more complication configurations as
different plugins or as configurations for the same plugin.

It should actually be fairly easy to move CMS 6's Xinha configuration
into a CMS 7 plugin.

The whole plugin concept is there to allow everyone to play around
with how you'd want *your* Hippo CMS 7 configured. This is something
that we had quite some trouble with in v6, since a change in
configuration demanded an entire rebuild. With 7 we're working towards
an entirely pluggable CMS framework, giving you all the tools to
create a CMS that works exactly like you want it to.

>> d. In Hippo 6 I can specify the preview urls, as well as limiting document
>> types in per directory bases. Can I do that in Hippo 7? (actually, where is
>> preview in Hippo 7?)
>
> This is actually one of HREPTWO's more interesting features. It is possible
> to to create whole trees of virtual repository nodes depending on the
> properties of an existing node. Out of the box the quickstart demo creates a
> 'live' and a 'preview' tree based on those nodes in the content tree which
> have a certain value in hippostd:state property. This is one of the benefits
> of the new extended support for facets in the repository. So for example if
> the CMS changes the property of a node from preview to live it will
> automatically become visible in the live tree when you next access the
> repository.

Spot on - this IS one of the most interesting features. :)

But my guess is that Jun is referring to the preview button, which we
had in the CMS 6 user interface that would open a new browser window
with a preview of the document you were editing. This should be very
simple to reimplement in v7, but we have much bigger plans :-)

With the new Hippo Site Toolkit 2.3 (in progress!), we're going to be
bringing in a framework that allows you to also design webPAGES from
within the CMS, not just content. The basic concepts for this new
toolkit come from our experience with the Portlet (JSR-168)
specification and the portal world. By combining components, and
storing configuration in the repository, you can create the outline of
a webpage using the CMS itself. Templates are created using some
templating language (currently defaulting to JSP, but Freemarker might
be next). The actual preview will then be within the CMS itself. But
hey, this is all very early. In a couple of weeks I expect to be able
to demonstrate this on my blog (blogs.hippo.nl/arje).

If you like living on the edge, grab the trunk here:
http://svn.onehippo.org/repos/hippo/ecm/site-toolkit/trunk/

>> a. how difficult would it be for us to migrate existing data and document
>> type definitions to hippo 7? We are talking about 30k+ documents here.

Of course, you're not the only user that raises this question. :) A
toolkit for migrating content is in the making.

>> That’s just a starter for all my questions on Hippo 7. I would really
>> appreciate it if someone could help me find my way around in Hippo 7.

More questions? Shoot!

HTH,

Arjé
_______________________________________________
Hippo-cms7-user mailing list and forums
http://www.onehippo.org/cms7/support/community.html
Reply | Threaded
Open this post in threaded view
|

Re: Hippo 6 vs Hippo 7

Niels van Kampenhout
Also, see the CMS Roadmap!

http://www.onehippo.org/cms7/about/roadmap.html

Regards,
Niels

On Thu, Mar 12, 2009 at 7:28 AM, Arje Cahn <[hidden email]> wrote:

> Hi Jun, David,
>
> Allow me to jump in  :-)
>
>> Running the CMS and the repository separately is on the roadmap as far as I
>> can see. The ability to import CMS6 content to CMS7 is also something that
>> is on the cards but not available right now.
>
> Yes, we will be splitting the CMS and the Repository just like we did
> in Hippo CMS 6.
> Technically speaking, they are already separated but there's a
> performance hit when you run them separated that we want to have
> resolved first. That's one of the things we're currently working on
> (Jackrabbit's SPI api). This is the issue you'll want to monitor:
> http://issues.onehippo.org/browse/HREPTWO-2055
>
>>> b. In Hippo 6, I was able to view the file content via http in the xml
>>> format I defined. Can I do that in Hippo 7? I know I can get to the file
>>> contents at http://localhost:8080/cms/repository/content, but it’s no longer
>>> a simple xml that I can just take and use? Are the contents now stored in
>>> different formats in Hippo 7?
>>
>> I'm also interested in the answer to this. My guess is that since CMS7 is
>> based on JCR section 6.4 'XML Mappings' should hold true. This means that it
>> should be possible to use the standard JCR functionality to export the
>> entire repository as XML which can then be imported by another JCR
>> installation without loss of information.
>
> Yes :)
> The console actually exposes this functionality
> (http://localhost:8080/cms/console). But that's not really the HTTP
> interface you're looking for.
>
> We're also discussing CMIS, Atom, REST, etc. Not decided which way to
> go yet, but having an HTTP interface to the Repository is definitely
> something worthwhile to have. For now, we're focusing on Java
> interfacing using the JCR. Adding an HTTP layer on top should not be a
> big deal, but we need some way of mapping nodes in the Repository to
> XML structures in a standardized way.
>
>>> c. What about webdav access to the repository?
>>
>> I have already asked about this and the answer seems to be that Webdav is
>> too slow
>
> Sorry, that must be a misunderstanding.. Of course, WebDAV has its
> uses - especially when storing content across a network. But when
> you're using Java, talking to the JCR directly is obviously the way to
> go. It also allows for a much better caching strategy too (see SPI
> layer).
>
> You could take a look at the Jackrabbit WebDAV Library:
> http://jackrabbit.apache.org/jackrabbit-webdav-library.html
>
>> However, it
>> seems that accessing the native JCR api through RMI is also too slow and the
>> trunk version of CMS7 is now using JackRabbit's SPI api through RMI.
>
> That's correct. The SPI layer will fix a lot of performance and
> caching issues. Also improves clustering.
>
>>> b. Hippo 6 had a lot of cool widgets, but we only seem to have a handful
>>> of them in Hippo 7. Do you have plans to add more widgets in?
>>
>> I'm sure they do.
>
> Yes we do :)
> Our focus is to give you a plugin framework with lots and lots of
> plugins (widgets/addons/etc). We're providing a forge installation on
> http://forge.onehippo.org, where everyone can host their own plugins
> (aka widgets). This is where all the action will be!
>
>> It's early days yet. Hippo have gone to a lot of trouble
>> to define the concept of 'addons'. These are things that we can make
>> ourselves if need be or get from the Hippo web site and simply extend the
>> Repository or CMS in any way we wish. Indeed the first 25 people to writean
>> interesting addon will get a Hippo T-Shirt!
>
> What are you waiting for, David!! :-D
>
>>> c. Hippo 6 uses Xinha as the rich text editor. It’s an older version with
>>> some issues, but it had the functionalities we wanted. What does Hippo 7
>>> uses? The rich text editor seems to have only limited functionalities (btw,
>>> I looked into the Rich Text Editor config email thread, and got completely
>>> lost there).
>>
>> CMS7 can use Xinha too. Not sure what version it is. Don't worry about the
>> apparent limited functionality. It is possible to turn bits on and off as
>> required and that was why I asked the question in that email thread.
>
> I think I can pretty much stop answering questions since you seem to
> cover all of them David ... ;)
> But you're correct. We're providing a very barebones Xinha plugin,
> with the intention of adding more complication configurations as
> different plugins or as configurations for the same plugin.
>
> It should actually be fairly easy to move CMS 6's Xinha configuration
> into a CMS 7 plugin.
>
> The whole plugin concept is there to allow everyone to play around
> with how you'd want *your* Hippo CMS 7 configured. This is something
> that we had quite some trouble with in v6, since a change in
> configuration demanded an entire rebuild. With 7 we're working towards
> an entirely pluggable CMS framework, giving you all the tools to
> create a CMS that works exactly like you want it to.
>
>>> d. In Hippo 6 I can specify the preview urls, as well as limiting document
>>> types in per directory bases. Can I do that in Hippo 7? (actually, where is
>>> preview in Hippo 7?)
>>
>> This is actually one of HREPTWO's more interesting features. It is possible
>> to to create whole trees of virtual repository nodes depending on the
>> properties of an existing node. Out of the box the quickstart demo creates a
>> 'live' and a 'preview' tree based on those nodes in the content tree which
>> have a certain value in hippostd:state property. This is one of the benefits
>> of the new extended support for facets in the repository. So for example if
>> the CMS changes the property of a node from preview to live it will
>> automatically become visible in the live tree when you next access the
>> repository.
>
> Spot on - this IS one of the most interesting features. :)
>
> But my guess is that Jun is referring to the preview button, which we
> had in the CMS 6 user interface that would open a new browser window
> with a preview of the document you were editing. This should be very
> simple to reimplement in v7, but we have much bigger plans :-)
>
> With the new Hippo Site Toolkit 2.3 (in progress!), we're going to be
> bringing in a framework that allows you to also design webPAGES from
> within the CMS, not just content. The basic concepts for this new
> toolkit come from our experience with the Portlet (JSR-168)
> specification and the portal world. By combining components, and
> storing configuration in the repository, you can create the outline of
> a webpage using the CMS itself. Templates are created using some
> templating language (currently defaulting to JSP, but Freemarker might
> be next). The actual preview will then be within the CMS itself. But
> hey, this is all very early. In a couple of weeks I expect to be able
> to demonstrate this on my blog (blogs.hippo.nl/arje).
>
> If you like living on the edge, grab the trunk here:
> http://svn.onehippo.org/repos/hippo/ecm/site-toolkit/trunk/
>
>>> a. how difficult would it be for us to migrate existing data and document
>>> type definitions to hippo 7? We are talking about 30k+ documents here.
>
> Of course, you're not the only user that raises this question. :) A
> toolkit for migrating content is in the making.
>
>>> That’s just a starter for all my questions on Hippo 7. I would really
>>> appreciate it if someone could help me find my way around in Hippo 7.
>
> More questions? Shoot!
>
> HTH,
>
> Arjé
> _______________________________________________
> Hippo-cms7-user mailing list and forums
> http://www.onehippo.org/cms7/support/community.html
>
_______________________________________________
Hippo-cms7-user mailing list and forums
http://www.onehippo.org/cms7/support/community.html
Reply | Threaded
Open this post in threaded view
|

RE: Hippo 6 vs Hippo 7

JunNi
Hi guys,
Thank you all for the detailed explanations!

David, yes, I was wondering why message didn't get posted earlier. I wasn't sure of the hippo 7 mail list so I took the shortcut of replying to a random msg. :p

Now I understand that Hippo 7 is still under development with a lot of new features on the way. It's also fundamentally different from Hippo 6. In summary:

1. Hippo 7 repository is based on JCR (Jackrabbit), not WebDav(Slide). Data is stored as node and properties in Hippo 7. There is the option of converting them into xml.

2. The preferred access method to the new repository is SPI, vs WebDav in Hippo 6. The querying method is xquery vs dasl in Hippo 6. (I think I saw xquery somewhere?) I am quite excited about that as dasl is just not easy to read/understand/debug. The issue there is we'll have to re-implement how our frontend app interacts with the new hippo.

3. All the hippo 6 features will be implemented in Hippo 7. We just need to give it more time. (http://www.onehippo.org/cms7/about/roadmap.html)

4. Repository and CMS will be separated once hippo solved the performance issue. Clustering is supported. There is a messaging system for notifications called observations.

5. Rich text editor is still xinha, and it is configurable.

6. Data migration from Hippo 6 is on the roadmap (June 2009). I assume that the migration tool will also address the porting of the existing document types and allowed document types on the directories? :p

7. Hippo Site Toolkit 2.3 sounds exciting. We did go through some head-scratching on where to store the templates, page definitions and how to do previews when deploying Hippo 6.  It would be nice if that problem can be addressed by Site Toolkit.


A couple more requests/questions:
1. Documentation
One of the reasons why we chose Hippo 6 was due to its excellent documentation. I can see that you guys are working hard on putting up documentations and how-to's. I found the console configuration very complex and confusing to me. So it will be great if we could have more documentation on that. (And yes, let me bring up the JCR API guide David mentioned. It is very helpful.)

2. More Xinha
Could someone please tell me which version of xinha is in Hippo 7? I did had great trouble with the rich text editor in Hippo 6. The older xinha version has a bug that it doesn't clean MS word tags when pasting on Firefox. I thought about upgrading it but was discouraged by the discussion. The demo I tried is 0.95, whose killWordOnPaste worked beautifully. It seems that this option is turned on by default in Hippo 7, but it is still not doing the bullets/numbered list conversion properly. I am not sure if it's merely the version of Xinha in Hippo, or if it's affected by any pre/post processing in hippo.

Thanks a lot!
Jun


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Niels van Kampenhout
Sent: Thursday, March 12, 2009 8:33 AM
To: Hippo CMS7 user list
Subject: Re: [Hippo-cms7-user] Hippo 6 vs Hippo 7

Also, see the CMS Roadmap!

http://www.onehippo.org/cms7/about/roadmap.html

Regards,
Niels

On Thu, Mar 12, 2009 at 7:28 AM, Arje Cahn <[hidden email]> wrote:

> Hi Jun, David,
>
> Allow me to jump in  :-)
>
>> Running the CMS and the repository separately is on the roadmap as far as I
>> can see. The ability to import CMS6 content to CMS7 is also something that
>> is on the cards but not available right now.
>
> Yes, we will be splitting the CMS and the Repository just like we did
> in Hippo CMS 6.
> Technically speaking, they are already separated but there's a
> performance hit when you run them separated that we want to have
> resolved first. That's one of the things we're currently working on
> (Jackrabbit's SPI api). This is the issue you'll want to monitor:
> http://issues.onehippo.org/browse/HREPTWO-2055
>
>>> b. In Hippo 6, I was able to view the file content via http in the xml
>>> format I defined. Can I do that in Hippo 7? I know I can get to the file
>>> contents at http://localhost:8080/cms/repository/content, but it's no longer
>>> a simple xml that I can just take and use? Are the contents now stored in
>>> different formats in Hippo 7?
>>
>> I'm also interested in the answer to this. My guess is that since CMS7 is
>> based on JCR section 6.4 'XML Mappings' should hold true. This means that it
>> should be possible to use the standard JCR functionality to export the
>> entire repository as XML which can then be imported by another JCR
>> installation without loss of information.
>
> Yes :)
> The console actually exposes this functionality
> (http://localhost:8080/cms/console). But that's not really the HTTP
> interface you're looking for.
>
> We're also discussing CMIS, Atom, REST, etc. Not decided which way to
> go yet, but having an HTTP interface to the Repository is definitely
> something worthwhile to have. For now, we're focusing on Java
> interfacing using the JCR. Adding an HTTP layer on top should not be a
> big deal, but we need some way of mapping nodes in the Repository to
> XML structures in a standardized way.
>
>>> c. What about webdav access to the repository?
>>
>> I have already asked about this and the answer seems to be that Webdav is
>> too slow
>
> Sorry, that must be a misunderstanding.. Of course, WebDAV has its
> uses - especially when storing content across a network. But when
> you're using Java, talking to the JCR directly is obviously the way to
> go. It also allows for a much better caching strategy too (see SPI
> layer).
>
> You could take a look at the Jackrabbit WebDAV Library:
> http://jackrabbit.apache.org/jackrabbit-webdav-library.html
>
>> However, it
>> seems that accessing the native JCR api through RMI is also too slow and the
>> trunk version of CMS7 is now using JackRabbit's SPI api through RMI.
>
> That's correct. The SPI layer will fix a lot of performance and
> caching issues. Also improves clustering.
>
>>> b. Hippo 6 had a lot of cool widgets, but we only seem to have a handful
>>> of them in Hippo 7. Do you have plans to add more widgets in?
>>
>> I'm sure they do.
>
> Yes we do :)
> Our focus is to give you a plugin framework with lots and lots of
> plugins (widgets/addons/etc). We're providing a forge installation on
> http://forge.onehippo.org, where everyone can host their own plugins
> (aka widgets). This is where all the action will be!
>
>> It's early days yet. Hippo have gone to a lot of trouble
>> to define the concept of 'addons'. These are things that we can make
>> ourselves if need be or get from the Hippo web site and simply extend the
>> Repository or CMS in any way we wish. Indeed the first 25 people to writean
>> interesting addon will get a Hippo T-Shirt!
>
> What are you waiting for, David!! :-D
>
>>> c. Hippo 6 uses Xinha as the rich text editor. It's an older version with
>>> some issues, but it had the functionalities we wanted. What does Hippo 7
>>> uses? The rich text editor seems to have only limited functionalities (btw,
>>> I looked into the Rich Text Editor config email thread, and got completely
>>> lost there).
>>
>> CMS7 can use Xinha too. Not sure what version it is. Don't worry about the
>> apparent limited functionality. It is possible to turn bits on and off as
>> required and that was why I asked the question in that email thread.
>
> I think I can pretty much stop answering questions since you seem to
> cover all of them David ... ;)
> But you're correct. We're providing a very barebones Xinha plugin,
> with the intention of adding more complication configurations as
> different plugins or as configurations for the same plugin.
>
> It should actually be fairly easy to move CMS 6's Xinha configuration
> into a CMS 7 plugin.
>
> The whole plugin concept is there to allow everyone to play around
> with how you'd want *your* Hippo CMS 7 configured. This is something
> that we had quite some trouble with in v6, since a change in
> configuration demanded an entire rebuild. With 7 we're working towards
> an entirely pluggable CMS framework, giving you all the tools to
> create a CMS that works exactly like you want it to.
>
>>> d. In Hippo 6 I can specify the preview urls, as well as limiting document
>>> types in per directory bases. Can I do that in Hippo 7? (actually, where is
>>> preview in Hippo 7?)
>>
>> This is actually one of HREPTWO's more interesting features. It is possible
>> to to create whole trees of virtual repository nodes depending on the
>> properties of an existing node. Out of the box the quickstart demo creates a
>> 'live' and a 'preview' tree based on those nodes in the content tree which
>> have a certain value in hippostd:state property. This is one of the benefits
>> of the new extended support for facets in the repository. So for example if
>> the CMS changes the property of a node from preview to live it will
>> automatically become visible in the live tree when you next access the
>> repository.
>
> Spot on - this IS one of the most interesting features. :)
>
> But my guess is that Jun is referring to the preview button, which we
> had in the CMS 6 user interface that would open a new browser window
> with a preview of the document you were editing. This should be very
> simple to reimplement in v7, but we have much bigger plans :-)
>
> With the new Hippo Site Toolkit 2.3 (in progress!), we're going to be
> bringing in a framework that allows you to also design webPAGES from
> within the CMS, not just content. The basic concepts for this new
> toolkit come from our experience with the Portlet (JSR-168)
> specification and the portal world. By combining components, and
> storing configuration in the repository, you can create the outline of
> a webpage using the CMS itself. Templates are created using some
> templating language (currently defaulting to JSP, but Freemarker might
> be next). The actual preview will then be within the CMS itself. But
> hey, this is all very early. In a couple of weeks I expect to be able
> to demonstrate this on my blog (blogs.hippo.nl/arje).
>
> If you like living on the edge, grab the trunk here:
> http://svn.onehippo.org/repos/hippo/ecm/site-toolkit/trunk/
>
>>> a. how difficult would it be for us to migrate existing data and document
>>> type definitions to hippo 7? We are talking about 30k+ documents here.
>
> Of course, you're not the only user that raises this question. :) A
> toolkit for migrating content is in the making.
>
>>> That's just a starter for all my questions on Hippo 7. I would really
>>> appreciate it if someone could help me find my way around in Hippo 7.
>
> More questions? Shoot!
>
> HTH,
>
> Arjé
> _______________________________________________
> Hippo-cms7-user mailing list and forums
> http://www.onehippo.org/cms7/support/community.html
>
_______________________________________________
Hippo-cms7-user mailing list and forums
http://www.onehippo.org/cms7/support/community.html

_______________________________________________
Hippo-cms7-user mailing list and forums
http://www.onehippo.org/cms7/support/community.html
Reply | Threaded
Open this post in threaded view
|

Re: Hippo 6 vs Hippo 7

Jeroen Reijn
Administrator
Hi Jun,

[hidden email] wrote:
> Hi guys,
> Thank you all for the detailed explanations!
>
> A couple more requests/questions:
> 1. Documentation
> One of the reasons why we chose Hippo 6 was due to its excellent documentation. I can see that you guys are working hard on putting up documentations and how-to's. I found the console configuration very complex and confusing to me. So it will be great if we could have more documentation on that. (And yes, let me bring up the JCR API guide David mentioned. It is very helpful.)
>

True. We're working very hard on our docs! Please give us as much
pointers as you like on what we are missing, so we can improve the docs.
We also have someone dedicated to our documentation now, which will
improve the amount and quality of docs a lot!

> 2. More Xinha
> Could someone please tell me which version of xinha is in Hippo 7? I did had great trouble with the rich text editor in Hippo 6. The older xinha version has a bug that it doesn't clean MS word tags when pasting on Firefox. I thought about upgrading it but was discouraged by the discussion. The demo I tried is 0.95, whose killWordOnPaste worked beautifully. It seems that this option is turned on by default in Hippo 7, but it is still not doing the bullets/numbered list conversion properly. I am not sure if it's merely the version of Xinha in Hippo, or if it's affected by any pre/post processing in hippo.

The only way I figured it out, was by looking at the code. We currently
are using revision 1137 of the xinha svn trunk
(http://svn.xinha.webfactional.com/trunk), which seems to be quite
stable though.

I spotted this by looking at the svn properties of [1]

Jeroen

[1]http://svn.hippocms.org/repos/hippo/hippo-ecm/tags/Tag-HREPTWO-v2_04_00/addon/xinha/src/main/webapp


>
> Thanks a lot!
> Jun
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Niels van Kampenhout
> Sent: Thursday, March 12, 2009 8:33 AM
> To: Hippo CMS7 user list
> Subject: Re: [Hippo-cms7-user] Hippo 6 vs Hippo 7
>
> Also, see the CMS Roadmap!
>
> http://www.onehippo.org/cms7/about/roadmap.html
>
> Regards,
> Niels
>
> On Thu, Mar 12, 2009 at 7:28 AM, Arje Cahn <[hidden email]> wrote:
>> Hi Jun, David,
>>
>> Allow me to jump in  :-)
>>
>>> Running the CMS and the repository separately is on the roadmap as far as I
>>> can see. The ability to import CMS6 content to CMS7 is also something that
>>> is on the cards but not available right now.
>> Yes, we will be splitting the CMS and the Repository just like we did
>> in Hippo CMS 6.
>> Technically speaking, they are already separated but there's a
>> performance hit when you run them separated that we want to have
>> resolved first. That's one of the things we're currently working on
>> (Jackrabbit's SPI api). This is the issue you'll want to monitor:
>> http://issues.onehippo.org/browse/HREPTWO-2055
>>
>>>> b. In Hippo 6, I was able to view the file content via http in the xml
>>>> format I defined. Can I do that in Hippo 7? I know I can get to the file
>>>> contents at http://localhost:8080/cms/repository/content, but it's no longer
>>>> a simple xml that I can just take and use? Are the contents now stored in
>>>> different formats in Hippo 7?
>>> I'm also interested in the answer to this. My guess is that since CMS7 is
>>> based on JCR section 6.4 'XML Mappings' should hold true. This means that it
>>> should be possible to use the standard JCR functionality to export the
>>> entire repository as XML which can then be imported by another JCR
>>> installation without loss of information.
>> Yes :)
>> The console actually exposes this functionality
>> (http://localhost:8080/cms/console). But that's not really the HTTP
>> interface you're looking for.
>>
>> We're also discussing CMIS, Atom, REST, etc. Not decided which way to
>> go yet, but having an HTTP interface to the Repository is definitely
>> something worthwhile to have. For now, we're focusing on Java
>> interfacing using the JCR. Adding an HTTP layer on top should not be a
>> big deal, but we need some way of mapping nodes in the Repository to
>> XML structures in a standardized way.
>>
>>>> c. What about webdav access to the repository?
>>> I have already asked about this and the answer seems to be that Webdav is
>>> too slow
>> Sorry, that must be a misunderstanding.. Of course, WebDAV has its
>> uses - especially when storing content across a network. But when
>> you're using Java, talking to the JCR directly is obviously the way to
>> go. It also allows for a much better caching strategy too (see SPI
>> layer).
>>
>> You could take a look at the Jackrabbit WebDAV Library:
>> http://jackrabbit.apache.org/jackrabbit-webdav-library.html
>>
>>> However, it
>>> seems that accessing the native JCR api through RMI is also too slow and the
>>> trunk version of CMS7 is now using JackRabbit's SPI api through RMI.
>> That's correct. The SPI layer will fix a lot of performance and
>> caching issues. Also improves clustering.
>>
>>>> b. Hippo 6 had a lot of cool widgets, but we only seem to have a handful
>>>> of them in Hippo 7. Do you have plans to add more widgets in?
>>> I'm sure they do.
>> Yes we do :)
>> Our focus is to give you a plugin framework with lots and lots of
>> plugins (widgets/addons/etc). We're providing a forge installation on
>> http://forge.onehippo.org, where everyone can host their own plugins
>> (aka widgets). This is where all the action will be!
>>
>>> It's early days yet. Hippo have gone to a lot of trouble
>>> to define the concept of 'addons'. These are things that we can make
>>> ourselves if need be or get from the Hippo web site and simply extend the
>>> Repository or CMS in any way we wish. Indeed the first 25 people to writean
>>> interesting addon will get a Hippo T-Shirt!
>> What are you waiting for, David!! :-D
>>
>>>> c. Hippo 6 uses Xinha as the rich text editor. It's an older version with
>>>> some issues, but it had the functionalities we wanted. What does Hippo 7
>>>> uses? The rich text editor seems to have only limited functionalities (btw,
>>>> I looked into the Rich Text Editor config email thread, and got completely
>>>> lost there).
>>> CMS7 can use Xinha too. Not sure what version it is. Don't worry about the
>>> apparent limited functionality. It is possible to turn bits on and off as
>>> required and that was why I asked the question in that email thread.
>> I think I can pretty much stop answering questions since you seem to
>> cover all of them David ... ;)
>> But you're correct. We're providing a very barebones Xinha plugin,
>> with the intention of adding more complication configurations as
>> different plugins or as configurations for the same plugin.
>>
>> It should actually be fairly easy to move CMS 6's Xinha configuration
>> into a CMS 7 plugin.
>>
>> The whole plugin concept is there to allow everyone to play around
>> with how you'd want *your* Hippo CMS 7 configured. This is something
>> that we had quite some trouble with in v6, since a change in
>> configuration demanded an entire rebuild. With 7 we're working towards
>> an entirely pluggable CMS framework, giving you all the tools to
>> create a CMS that works exactly like you want it to.
>>
>>>> d. In Hippo 6 I can specify the preview urls, as well as limiting document
>>>> types in per directory bases. Can I do that in Hippo 7? (actually, where is
>>>> preview in Hippo 7?)
>>> This is actually one of HREPTWO's more interesting features. It is possible
>>> to to create whole trees of virtual repository nodes depending on the
>>> properties of an existing node. Out of the box the quickstart demo creates a
>>> 'live' and a 'preview' tree based on those nodes in the content tree which
>>> have a certain value in hippostd:state property. This is one of the benefits
>>> of the new extended support for facets in the repository. So for example if
>>> the CMS changes the property of a node from preview to live it will
>>> automatically become visible in the live tree when you next access the
>>> repository.
>> Spot on - this IS one of the most interesting features. :)
>>
>> But my guess is that Jun is referring to the preview button, which we
>> had in the CMS 6 user interface that would open a new browser window
>> with a preview of the document you were editing. This should be very
>> simple to reimplement in v7, but we have much bigger plans :-)
>>
>> With the new Hippo Site Toolkit 2.3 (in progress!), we're going to be
>> bringing in a framework that allows you to also design webPAGES from
>> within the CMS, not just content. The basic concepts for this new
>> toolkit come from our experience with the Portlet (JSR-168)
>> specification and the portal world. By combining components, and
>> storing configuration in the repository, you can create the outline of
>> a webpage using the CMS itself. Templates are created using some
>> templating language (currently defaulting to JSP, but Freemarker might
>> be next). The actual preview will then be within the CMS itself. But
>> hey, this is all very early. In a couple of weeks I expect to be able
>> to demonstrate this on my blog (blogs.hippo.nl/arje).
>>
>> If you like living on the edge, grab the trunk here:
>> http://svn.onehippo.org/repos/hippo/ecm/site-toolkit/trunk/
>>
>>>> a. how difficult would it be for us to migrate existing data and document
>>>> type definitions to hippo 7? We are talking about 30k+ documents here.
>> Of course, you're not the only user that raises this question. :) A
>> toolkit for migrating content is in the making.
>>
>>>> That's just a starter for all my questions on Hippo 7. I would really
>>>> appreciate it if someone could help me find my way around in Hippo 7.
>> More questions? Shoot!
>>
>> HTH,
>>
>> Arjé
>> _______________________________________________
>> Hippo-cms7-user mailing list and forums
>> http://www.onehippo.org/cms7/support/community.html
>>
> _______________________________________________
> Hippo-cms7-user mailing list and forums
> http://www.onehippo.org/cms7/support/community.html
>
> _______________________________________________
> Hippo-cms7-user mailing list and forums
> http://www.onehippo.org/cms7/support/community.html
_______________________________________________
Hippo-cms7-user mailing list and forums
http://www.onehippo.org/cms7/support/community.html
12