You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by unimatrixzero <wa...@isogmbh.de> on 2007/12/07 14:36:30 UTC
Web Content Management Systems
Hi!
I'm currently testing a few Open Source WCMS Systems like OpenCms and
Magnolia (Java based).
All this WCMS using JSP's for Templates (together with a own Taglib) and
Magnolia stores the Content
in an JSR-170 Java Content Repository. I'm wondering if it is possible to
integrate some Content
from this Content Management System into a Tapestry Application. Goal would
be that the user
is able to modify content in the Content Management System (like writing an
article or adding a picture)
and this content could be then included in Tapestry. Is this in some way
possible?
One of the greatest problems is that Tapestry uses his own kind of templates
and OpenCms and Magnolia the JSP ones.
Do you think there is a way to integrate this two things?
Maybe you could help me.
Thank you in advance.
--
View this message in context: http://www.nabble.com/Web-Content-Management-Systems-tf4962087.html#a14212538
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Web Content Management Systems
Posted by unimatrixzero <wa...@isogmbh.de>.
Thank's for the answers.
> You could write some components against the JCR API and access the
> underlying repository Magnolia uses (I don't know if this is possible
> with OpenCms).
Yes, to connect from (Tapestry) Web App to the JCR Repository was also my
first idea.
The basic question about this aproach would be: How the editor in Magnolia
sees the Layout of the Site?
Basically, Magnolia uses JSP's as Templates which is own Taglib. So, if i
edit content in Magnolia i need some sort of JSP Template which is the same
as in Tapestry, because the Editor needs to see what the site is look like
in the preview.
I guess i could get everything that is in the JCR Repository what the Author
creates (access the properties of the nodes in the JCR Repository) but how
the Editor of the site sees the actual site and could edit it in Magnolia
when we didn't have a JSP Template?
I'm new to Tapestry so please correct my if i'm wrong.
Thank's in advance.
Ulrich Stärk wrote:
>
> Performance will vary greatly depending upon which strategy your JCR
> implementation uses to persist items. The type and amount of items you
> want to store in your repository will also influence performance. For
> you, storing thousands of thumbnails in a repository might not have been
> the right solution. But I think that in order to facilitate the
> maintenance of dynamic Tapestry applications an interface to a content
> repository is a good idea. You don't have to tinker with the templates
> just because you want some different text on your pages. Any editor can
> do it through a web interface like Magnolia. No need to annoy your
> application programmer with this.
>
> Cheers,
>
> Uli
>
> Phillip Rhodes schrieb:
>> I did write some tapestry components to search, display, upload, modify
>> contents in a JCR repository, but after we loaded a few hundred images
>> into the repo, our application slowed to a crawl. The problem (and it's
>> a common one for many repositories) was that to return a content item,
>> the repository has to retrieve all attributes for the node, and this was
>> a separate select statement. So if your repository has 100 images in it,
>> it would be doing 100+ sql queries to build up the nodes. Once it's
>> loaded, it can be cached, but this was not a viable option since
>> performance was critical for me, and we have 1000's of images.
>>
>> I am just sharing my experience with you so that you consider the
>> performance of returning 100 thumbnails on your tapestry page in your
>> design.
>>
>> In the end, I wrote my tapestry components access a SpringService that
>> sits on top of a compass/lucene file system repository for images,
>> content. The SpringService is remotable so that I have many application
>> servers running against the central repository server. Next on the
>> roadmap is to implement the backend storage to be amazon s3. Performance
>> is good because for example, all the information to display a image is
>> returned in a single lucene document. meta information for the content
>> is stored in the filesystem as xml files.
>>
>> Phillip
>>
>> ----- Original Message -----
>> From: "Ulrich Stärk" <ul...@spielviel.de>
>> To: "Tapestry users" <us...@tapestry.apache.org>
>> Sent: Friday, December 7, 2007 9:45:01 AM (GMT-0500) America/New_York
>> Subject: Re: Web Content Management Systems
>>
>> You could write some components against the JCR API and access the
>> underlying repository Magnolia uses (I don't know if this is possible
>> with OpenCms).
>> Have a look at the Jackrabbit website (that's the repository
>> implementation Magnolia uses) to learn how to register the repository
>> with JNDI. Then just configure Magnolia to use that one instead of the
>> preconfigured location. Afterwards you are able to also access the
>> repository from your tapestry webapp with a JNDI lookup. This approach
>> has some security flaws though. Magnolia has its own security checks and
>> connects to the repository through just one user. If you access the
>> repository directly you bypass Magnolias security layer.
>> The Jackrabbit website shows how to register the repository with JNDI in
>> the local web context. So you only have access to the repository in the
>> context where you registered it. In order to have your Tapestry app and
>> Magnolia live in different contexts and still access the same repository
>> you will have to register it globally thus making it available to ALL
>> contexts in your container. In combination with the above mentioned this
>> can have serious impacts on security. So be careful what you do.
>>
>> Cheers,
>>
>> Uli
>>
>> unimatrixzero schrieb:
>>> Hi!
>>>
>>> I'm currently testing a few Open Source WCMS Systems like OpenCms and
>>> Magnolia (Java based).
>>> All this WCMS using JSP's for Templates (together with a own Taglib) and
>>> Magnolia stores the Content
>>> in an JSR-170 Java Content Repository. I'm wondering if it is possible
>>> to
>>> integrate some Content
>>> from this Content Management System into a Tapestry Application. Goal
>>> would
>>> be that the user
>>> is able to modify content in the Content Management System (like writing
>>> an
>>> article or adding a picture)
>>> and this content could be then included in Tapestry. Is this in some way
>>> possible?
>>> One of the greatest problems is that Tapestry uses his own kind of
>>> templates
>>> and OpenCms and Magnolia the JSP ones.
>>> Do you think there is a way to integrate this two things?
>>>
>>> Maybe you could help me.
>>> Thank you in advance.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Web-Content-Management-Systems-tf4962087.html#a14216443
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Web Content Management Systems
Posted by Daniel Honig <da...@gmail.com>.
If you are using Magnolia I have integrated Magnolia with a grails
application recently. I created my own mechanism that works through
JNDI to access a Magnolia session. As more of a guess than a well
researched design, I'm pooling sessions with the open session in view
pattern. This seems to work pretty well for me. I'm curious if you
the pooling of JCR sessions is really necessary or a case of overkill?
On Wed, Nov 12, 2008 at 7:29 AM, srawilliams <se...@gmail.com> wrote:
>
> Hi Mike,
>
> Did you get anywhere with this. If you need some collaboration, I am about
> to try and solve the same problem.
>
> Sean
>
>
>
>
> I believe I'm working on what you seek.
>
> I'm working on a project which extends tapestry 5 to pull page/
> component templates from an external data store.
>
> Where Tapestry pages are normally pulled from the classpath: or the
> context:, I've added another option(http:) which pulls page/component
> templates from itself(localhost) on a separate(non-tapestry) servlet
> app.
> While this has the added work of opening another http connection for
> the page/component being accessed, the resulting template is stored
> in tapestry's cache and could be invalidated when an update is made to
> the database. I'm trying my best to do this without making
> changes to tapestry's base code. Now that I've gotten familiar with
> the IoC container, I'm comfortable enough to inject and override a
> couple
> of tapestry's core services. If I'm lucky, creating a tapestry-centric
> cms should be as easy as dropping a jar in with tapestry which will
> auto-load its tapesty-specific AppModule class.
>
> I know..I'm tooling with services from behind the
> org.apache.tapestry.internal curtain while the framework itself is
> technically unreleased.
> I'm running a risk here, but hopefully the interfaces won't change too
> much for the few services I'm overriding.
>
> So far I'm achieving this by overriding the following services with ioc:
> http://tapestry.formos.com/nightly/tapestry5/apidocs/org/apache/tapestry/internal/services/PageTemplateLocator.html
> http://tapestry.formos.com/nightly/tapestry5/apidocs/org/apache/tapestry/internal/services/ComponentTemplateSource.html
>
> without touching the base code, I'm able to get tapestry to pull the
> templates from something other than the context or classpath. It's a
> mini-success.
>
> What I really envision though, are page/component templates that are
> specific to the hostname being used in the request. I'm able to make
> this
> work by contributing my own ComponentClassResolver which uses an ugly
> hack to tack on the hostname to the primary key used in the cache.
> (luckily it's one of the few services where I can extend howard's
> implementation and just override a couple methods - many of the other
> services are marked "final")
>
> I'm halfway there, http://localhost:8080/start and
> http://127.0.0.1:8080/start
> now pull two separate page templates from the database and work with
> tapestry's cache.
>
> What I REALLY want is the ability to change the location component
> templates are "searched for" to be in the following places in the
> following order:
> 1 - the database(using http: and a servlet, or perhaps jndi?)
> 1a - by hostname, page name and component id
> 1b - by hostname and page name
> 1c - by hostname
> 2 - fall back to its classpath resource in ".components." package
>
> eg:
> http://localhost:8080/templateservlet/localhost/org.example.app.components.withexternaltemplates.LoginForm:MyLoginPage:myloginform_en.tml
> http://localhost:8080/templateservlet/localhost/org.example.app.components.withexternaltemplates.LoginForm:MyLoginPage_en.tml
> http://localhost:8080/templateservlet/localhost/org.example.app.components.withexternaltemplates.LoginForm_en.tml
> classpath:org
> .example.app.components.withexternaltemplates.LoginForm_en.tml
> classpath:org.example.app.components.withexternaltemplates.LoginForm.tml
>
> (yeah, all the locale stuff should also stick)
>
> The real-world example: we are to maintain dozens of sites which each
> use a login form. The logic behind the login form will not change that
> much between sites but the appearance for each site should be different.
> The application programmer creates a component class (LoginForm) and a
> "functioning" component template which are developed and packaged
> together.
> Through a web-based page builder, the web designer might create a new
> site which needs a login form. Wouldn't it be cool if the designer
> could drag and drop from a palette of "web-editable" tapestry
> components to the page? When the component is dropped on the page, it
> would use the "most matching"(based on hostname, page, id) component
> template available but always be able to fall back on the original
> login form template(from the classpath) which was written by the
> application programmer(and is most likely UGLY).
> If the designer wanted to change the appearance of the login form,
> they would click an admin-only control which would allow them to edit
> a copy of the programmer's TML(from the classpath) which would be
> saved to the database. Upon saving, an invalidation event would fire,
> and tapestry's template cache would clear, and thus, the next request
> for that component would bring its updated template down from the
> database and be stored in tapestry's cache.
>
> I'm thinking these "special" components should be treated almost as
> portlets for a portal system. Each faux portlet could be
> "configurable" from the web with persisting configuration options(in
> addition to being able to modify the template).
>
> Could some core developers chime in on whether they think this is
> feasible? anyone have any thoughts on this?
>
> If someone wants to collaborate with me, I'd be happy to do so.
>
> --
> View this message in context: http://www.nabble.com/Web-Content-Management-Systems-tp14212538p20459391.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Web Content Management Systems
Posted by srawilliams <se...@gmail.com>.
Hi Mike,
Did you get anywhere with this. If you need some collaboration, I am about
to try and solve the same problem.
Sean
I believe I'm working on what you seek.
I'm working on a project which extends tapestry 5 to pull page/
component templates from an external data store.
Where Tapestry pages are normally pulled from the classpath: or the
context:, I've added another option(http:) which pulls page/component
templates from itself(localhost) on a separate(non-tapestry) servlet
app.
While this has the added work of opening another http connection for
the page/component being accessed, the resulting template is stored
in tapestry's cache and could be invalidated when an update is made to
the database. I'm trying my best to do this without making
changes to tapestry's base code. Now that I've gotten familiar with
the IoC container, I'm comfortable enough to inject and override a
couple
of tapestry's core services. If I'm lucky, creating a tapestry-centric
cms should be as easy as dropping a jar in with tapestry which will
auto-load its tapesty-specific AppModule class.
I know..I'm tooling with services from behind the
org.apache.tapestry.internal curtain while the framework itself is
technically unreleased.
I'm running a risk here, but hopefully the interfaces won't change too
much for the few services I'm overriding.
So far I'm achieving this by overriding the following services with ioc:
http://tapestry.formos.com/nightly/tapestry5/apidocs/org/apache/tapestry/internal/services/PageTemplateLocator.html
http://tapestry.formos.com/nightly/tapestry5/apidocs/org/apache/tapestry/internal/services/ComponentTemplateSource.html
without touching the base code, I'm able to get tapestry to pull the
templates from something other than the context or classpath. It's a
mini-success.
What I really envision though, are page/component templates that are
specific to the hostname being used in the request. I'm able to make
this
work by contributing my own ComponentClassResolver which uses an ugly
hack to tack on the hostname to the primary key used in the cache.
(luckily it's one of the few services where I can extend howard's
implementation and just override a couple methods - many of the other
services are marked "final")
I'm halfway there, http://localhost:8080/start and
http://127.0.0.1:8080/start
now pull two separate page templates from the database and work with
tapestry's cache.
What I REALLY want is the ability to change the location component
templates are "searched for" to be in the following places in the
following order:
1 - the database(using http: and a servlet, or perhaps jndi?)
1a - by hostname, page name and component id
1b - by hostname and page name
1c - by hostname
2 - fall back to its classpath resource in ".components." package
eg:
http://localhost:8080/templateservlet/localhost/org.example.app.components.withexternaltemplates.LoginForm:MyLoginPage:myloginform_en.tml
http://localhost:8080/templateservlet/localhost/org.example.app.components.withexternaltemplates.LoginForm:MyLoginPage_en.tml
http://localhost:8080/templateservlet/localhost/org.example.app.components.withexternaltemplates.LoginForm_en.tml
classpath:org
.example.app.components.withexternaltemplates.LoginForm_en.tml
classpath:org.example.app.components.withexternaltemplates.LoginForm.tml
(yeah, all the locale stuff should also stick)
The real-world example: we are to maintain dozens of sites which each
use a login form. The logic behind the login form will not change that
much between sites but the appearance for each site should be different.
The application programmer creates a component class (LoginForm) and a
"functioning" component template which are developed and packaged
together.
Through a web-based page builder, the web designer might create a new
site which needs a login form. Wouldn't it be cool if the designer
could drag and drop from a palette of "web-editable" tapestry
components to the page? When the component is dropped on the page, it
would use the "most matching"(based on hostname, page, id) component
template available but always be able to fall back on the original
login form template(from the classpath) which was written by the
application programmer(and is most likely UGLY).
If the designer wanted to change the appearance of the login form,
they would click an admin-only control which would allow them to edit
a copy of the programmer's TML(from the classpath) which would be
saved to the database. Upon saving, an invalidation event would fire,
and tapestry's template cache would clear, and thus, the next request
for that component would bring its updated template down from the
database and be stored in tapestry's cache.
I'm thinking these "special" components should be treated almost as
portlets for a portal system. Each faux portlet could be
"configurable" from the web with persisting configuration options(in
addition to being able to modify the template).
Could some core developers chime in on whether they think this is
feasible? anyone have any thoughts on this?
If someone wants to collaborate with me, I'd be happy to do so.
--
View this message in context: http://www.nabble.com/Web-Content-Management-Systems-tp14212538p20459391.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Web Content Management Systems
Posted by Michael Lake <ml...@netvue.com>.
I believe I'm working on what you seek.
I'm working on a project which extends tapestry 5 to pull page/
component templates from an external data store.
Where Tapestry pages are normally pulled from the classpath: or the
context:, I've added another option(http:) which pulls page/component
templates from itself(localhost) on a separate(non-tapestry) servlet
app.
While this has the added work of opening another http connection for
the page/component being accessed, the resulting template is stored
in tapestry's cache and could be invalidated when an update is made to
the database. I'm trying my best to do this without making
changes to tapestry's base code. Now that I've gotten familiar with
the IoC container, I'm comfortable enough to inject and override a
couple
of tapestry's core services. If I'm lucky, creating a tapestry-centric
cms should be as easy as dropping a jar in with tapestry which will
auto-load its tapesty-specific AppModule class.
I know..I'm tooling with services from behind the
org.apache.tapestry.internal curtain while the framework itself is
technically unreleased.
I'm running a risk here, but hopefully the interfaces won't change too
much for the few services I'm overriding.
So far I'm achieving this by overriding the following services with ioc:
http://tapestry.formos.com/nightly/tapestry5/apidocs/org/apache/tapestry/internal/services/PageTemplateLocator.html
http://tapestry.formos.com/nightly/tapestry5/apidocs/org/apache/tapestry/internal/services/ComponentTemplateSource.html
without touching the base code, I'm able to get tapestry to pull the
templates from something other than the context or classpath. It's a
mini-success.
What I really envision though, are page/component templates that are
specific to the hostname being used in the request. I'm able to make
this
work by contributing my own ComponentClassResolver which uses an ugly
hack to tack on the hostname to the primary key used in the cache.
(luckily it's one of the few services where I can extend howard's
implementation and just override a couple methods - many of the other
services are marked "final")
I'm halfway there, http://localhost:8080/start and http://127.0.0.1:8080/start
now pull two separate page templates from the database and work with
tapestry's cache.
What I REALLY want is the ability to change the location component
templates are "searched for" to be in the following places in the
following order:
1 - the database(using http: and a servlet, or perhaps jndi?)
1a - by hostname, page name and component id
1b - by hostname and page name
1c - by hostname
2 - fall back to its classpath resource in ".components." package
eg:
http://localhost:8080/templateservlet/localhost/org.example.app.components.withexternaltemplates.LoginForm:MyLoginPage:myloginform_en.tml
http://localhost:8080/templateservlet/localhost/org.example.app.components.withexternaltemplates.LoginForm:MyLoginPage_en.tml
http://localhost:8080/templateservlet/localhost/org.example.app.components.withexternaltemplates.LoginForm_en.tml
classpath:org
.example.app.components.withexternaltemplates.LoginForm_en.tml
classpath:org.example.app.components.withexternaltemplates.LoginForm.tml
(yeah, all the locale stuff should also stick)
The real-world example: we are to maintain dozens of sites which each
use a login form. The logic behind the login form will not change that
much between sites but the appearance for each site should be different.
The application programmer creates a component class (LoginForm) and a
"functioning" component template which are developed and packaged
together.
Through a web-based page builder, the web designer might create a new
site which needs a login form. Wouldn't it be cool if the designer
could drag and drop from a palette of "web-editable" tapestry
components to the page? When the component is dropped on the page, it
would use the "most matching"(based on hostname, page, id) component
template available but always be able to fall back on the original
login form template(from the classpath) which was written by the
application programmer(and is most likely UGLY).
If the designer wanted to change the appearance of the login form,
they would click an admin-only control which would allow them to edit
a copy of the programmer's TML(from the classpath) which would be
saved to the database. Upon saving, an invalidation event would fire,
and tapestry's template cache would clear, and thus, the next request
for that component would bring its updated template down from the
database and be stored in tapestry's cache.
I'm thinking these "special" components should be treated almost as
portlets for a portal system. Each faux portlet could be
"configurable" from the web with persisting configuration options(in
addition to being able to modify the template).
Could some core developers chime in on whether they think this is
feasible? anyone have any thoughts on this?
If someone wants to collaborate with me, I'd be happy to do so.
-mike
On Dec 7, 2007, at 10:45 AM, Ulrich Stärk wrote:
> Performance will vary greatly depending upon which strategy your JCR
> implementation uses to persist items. The type and amount of items
> you want to store in your repository will also influence
> performance. For you, storing thousands of thumbnails in a
> repository might not have been the right solution. But I think that
> in order to facilitate the maintenance of dynamic Tapestry
> applications an interface to a content repository is a good idea.
> You don't have to tinker with the templates just because you want
> some different text on your pages. Any editor can do it through a
> web interface like Magnolia. No need to annoy your application
> programmer with this.
>
> Cheers,
>
> Uli
>
> Phillip Rhodes schrieb:
>> I did write some tapestry components to search, display, upload,
>> modify contents in a JCR repository, but after we loaded a few
>> hundred images into the repo, our application slowed to a crawl.
>> The problem (and it's a common one for many repositories) was that
>> to return a content item, the repository has to retrieve all
>> attributes for the node, and this was a separate select statement.
>> So if your repository has 100 images in it, it would be doing 100+
>> sql queries to build up the nodes. Once it's loaded, it can be
>> cached, but this was not a viable option since performance was
>> critical for me, and we have 1000's of images.
>> I am just sharing my experience with you so that you consider the
>> performance of returning 100 thumbnails on your tapestry page in
>> your design.
>> In the end, I wrote my tapestry components access a SpringService
>> that sits on top of a compass/lucene file system repository for
>> images, content. The SpringService is remotable so that I have
>> many application servers running against the central repository
>> server. Next on the roadmap is to implement the backend storage to
>> be amazon s3. Performance is good because for example, all the
>> information to display a image is returned in a single lucene
>> document. meta information for the content is stored in the
>> filesystem as xml files.
>> Phillip
>> ----- Original Message -----
>> From: "Ulrich Stärk" <ul...@spielviel.de>
>> To: "Tapestry users" <us...@tapestry.apache.org>
>> Sent: Friday, December 7, 2007 9:45:01 AM (GMT-0500) America/New_York
>> Subject: Re: Web Content Management Systems
>> You could write some components against the JCR API and access the
>> underlying repository Magnolia uses (I don't know if this is
>> possible with OpenCms).
>> Have a look at the Jackrabbit website (that's the repository
>> implementation Magnolia uses) to learn how to register the
>> repository with JNDI. Then just configure Magnolia to use that one
>> instead of the preconfigured location. Afterwards you are able to
>> also access the repository from your tapestry webapp with a JNDI
>> lookup. This approach has some security flaws though. Magnolia has
>> its own security checks and connects to the repository through just
>> one user. If you access the repository directly you bypass
>> Magnolias security layer.
>> The Jackrabbit website shows how to register the repository with
>> JNDI in the local web context. So you only have access to the
>> repository in the context where you registered it. In order to have
>> your Tapestry app and Magnolia live in different contexts and still
>> access the same repository you will have to register it globally
>> thus making it available to ALL contexts in your container. In
>> combination with the above mentioned this can have serious impacts
>> on security. So be careful what you do.
>> Cheers,
>> Uli
>> unimatrixzero schrieb:
>>> Hi!
>>>
>>> I'm currently testing a few Open Source WCMS Systems like OpenCms
>>> and
>>> Magnolia (Java based).
>>> All this WCMS using JSP's for Templates (together with a own
>>> Taglib) and
>>> Magnolia stores the Content
>>> in an JSR-170 Java Content Repository. I'm wondering if it is
>>> possible to
>>> integrate some Content
>>> from this Content Management System into a Tapestry Application.
>>> Goal would
>>> be that the user
>>> is able to modify content in the Content Management System (like
>>> writing an
>>> article or adding a picture)
>>> and this content could be then included in Tapestry. Is this in
>>> some way
>>> possible?
>>> One of the greatest problems is that Tapestry uses his own kind of
>>> templates
>>> and OpenCms and Magnolia the JSP ones.
>>> Do you think there is a way to integrate this two things?
>>>
>>> Maybe you could help me.
>>> Thank you in advance.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Web Content Management Systems
Posted by Ulrich Stärk <ul...@spielviel.de>.
Performance will vary greatly depending upon which strategy your JCR
implementation uses to persist items. The type and amount of items you
want to store in your repository will also influence performance. For
you, storing thousands of thumbnails in a repository might not have been
the right solution. But I think that in order to facilitate the
maintenance of dynamic Tapestry applications an interface to a content
repository is a good idea. You don't have to tinker with the templates
just because you want some different text on your pages. Any editor can
do it through a web interface like Magnolia. No need to annoy your
application programmer with this.
Cheers,
Uli
Phillip Rhodes schrieb:
> I did write some tapestry components to search, display, upload, modify contents in a JCR repository, but after we loaded a few hundred images into the repo, our application slowed to a crawl. The problem (and it's a common one for many repositories) was that to return a content item, the repository has to retrieve all attributes for the node, and this was a separate select statement. So if your repository has 100 images in it, it would be doing 100+ sql queries to build up the nodes. Once it's loaded, it can be cached, but this was not a viable option since performance was critical for me, and we have 1000's of images.
>
> I am just sharing my experience with you so that you consider the performance of returning 100 thumbnails on your tapestry page in your design.
>
> In the end, I wrote my tapestry components access a SpringService that sits on top of a compass/lucene file system repository for images, content. The SpringService is remotable so that I have many application servers running against the central repository server. Next on the roadmap is to implement the backend storage to be amazon s3. Performance is good because for example, all the information to display a image is returned in a single lucene document. meta information for the content is stored in the filesystem as xml files.
>
> Phillip
>
> ----- Original Message -----
> From: "Ulrich Stärk" <ul...@spielviel.de>
> To: "Tapestry users" <us...@tapestry.apache.org>
> Sent: Friday, December 7, 2007 9:45:01 AM (GMT-0500) America/New_York
> Subject: Re: Web Content Management Systems
>
> You could write some components against the JCR API and access the
> underlying repository Magnolia uses (I don't know if this is possible
> with OpenCms).
> Have a look at the Jackrabbit website (that's the repository
> implementation Magnolia uses) to learn how to register the repository
> with JNDI. Then just configure Magnolia to use that one instead of the
> preconfigured location. Afterwards you are able to also access the
> repository from your tapestry webapp with a JNDI lookup. This approach
> has some security flaws though. Magnolia has its own security checks and
> connects to the repository through just one user. If you access the
> repository directly you bypass Magnolias security layer.
> The Jackrabbit website shows how to register the repository with JNDI in
> the local web context. So you only have access to the repository in the
> context where you registered it. In order to have your Tapestry app and
> Magnolia live in different contexts and still access the same repository
> you will have to register it globally thus making it available to ALL
> contexts in your container. In combination with the above mentioned this
> can have serious impacts on security. So be careful what you do.
>
> Cheers,
>
> Uli
>
> unimatrixzero schrieb:
>> Hi!
>>
>> I'm currently testing a few Open Source WCMS Systems like OpenCms and
>> Magnolia (Java based).
>> All this WCMS using JSP's for Templates (together with a own Taglib) and
>> Magnolia stores the Content
>> in an JSR-170 Java Content Repository. I'm wondering if it is possible to
>> integrate some Content
>> from this Content Management System into a Tapestry Application. Goal would
>> be that the user
>> is able to modify content in the Content Management System (like writing an
>> article or adding a picture)
>> and this content could be then included in Tapestry. Is this in some way
>> possible?
>> One of the greatest problems is that Tapestry uses his own kind of templates
>> and OpenCms and Magnolia the JSP ones.
>> Do you think there is a way to integrate this two things?
>>
>> Maybe you could help me.
>> Thank you in advance.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Web Content Management Systems
Posted by Phillip Rhodes <sp...@rhoderunner.com>.
I did write some tapestry components to search, display, upload, modify contents in a JCR repository, but after we loaded a few hundred images into the repo, our application slowed to a crawl. The problem (and it's a common one for many repositories) was that to return a content item, the repository has to retrieve all attributes for the node, and this was a separate select statement. So if your repository has 100 images in it, it would be doing 100+ sql queries to build up the nodes. Once it's loaded, it can be cached, but this was not a viable option since performance was critical for me, and we have 1000's of images.
I am just sharing my experience with you so that you consider the performance of returning 100 thumbnails on your tapestry page in your design.
In the end, I wrote my tapestry components access a SpringService that sits on top of a compass/lucene file system repository for images, content. The SpringService is remotable so that I have many application servers running against the central repository server. Next on the roadmap is to implement the backend storage to be amazon s3. Performance is good because for example, all the information to display a image is returned in a single lucene document. meta information for the content is stored in the filesystem as xml files.
Phillip
----- Original Message -----
From: "Ulrich Stärk" <ul...@spielviel.de>
To: "Tapestry users" <us...@tapestry.apache.org>
Sent: Friday, December 7, 2007 9:45:01 AM (GMT-0500) America/New_York
Subject: Re: Web Content Management Systems
You could write some components against the JCR API and access the
underlying repository Magnolia uses (I don't know if this is possible
with OpenCms).
Have a look at the Jackrabbit website (that's the repository
implementation Magnolia uses) to learn how to register the repository
with JNDI. Then just configure Magnolia to use that one instead of the
preconfigured location. Afterwards you are able to also access the
repository from your tapestry webapp with a JNDI lookup. This approach
has some security flaws though. Magnolia has its own security checks and
connects to the repository through just one user. If you access the
repository directly you bypass Magnolias security layer.
The Jackrabbit website shows how to register the repository with JNDI in
the local web context. So you only have access to the repository in the
context where you registered it. In order to have your Tapestry app and
Magnolia live in different contexts and still access the same repository
you will have to register it globally thus making it available to ALL
contexts in your container. In combination with the above mentioned this
can have serious impacts on security. So be careful what you do.
Cheers,
Uli
unimatrixzero schrieb:
> Hi!
>
> I'm currently testing a few Open Source WCMS Systems like OpenCms and
> Magnolia (Java based).
> All this WCMS using JSP's for Templates (together with a own Taglib) and
> Magnolia stores the Content
> in an JSR-170 Java Content Repository. I'm wondering if it is possible to
> integrate some Content
> from this Content Management System into a Tapestry Application. Goal would
> be that the user
> is able to modify content in the Content Management System (like writing an
> article or adding a picture)
> and this content could be then included in Tapestry. Is this in some way
> possible?
> One of the greatest problems is that Tapestry uses his own kind of templates
> and OpenCms and Magnolia the JSP ones.
> Do you think there is a way to integrate this two things?
>
> Maybe you could help me.
> Thank you in advance.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Web Content Management Systems
Posted by Ulrich Stärk <ul...@spielviel.de>.
You could write some components against the JCR API and access the
underlying repository Magnolia uses (I don't know if this is possible
with OpenCms).
Have a look at the Jackrabbit website (that's the repository
implementation Magnolia uses) to learn how to register the repository
with JNDI. Then just configure Magnolia to use that one instead of the
preconfigured location. Afterwards you are able to also access the
repository from your tapestry webapp with a JNDI lookup. This approach
has some security flaws though. Magnolia has its own security checks and
connects to the repository through just one user. If you access the
repository directly you bypass Magnolias security layer.
The Jackrabbit website shows how to register the repository with JNDI in
the local web context. So you only have access to the repository in the
context where you registered it. In order to have your Tapestry app and
Magnolia live in different contexts and still access the same repository
you will have to register it globally thus making it available to ALL
contexts in your container. In combination with the above mentioned this
can have serious impacts on security. So be careful what you do.
Cheers,
Uli
unimatrixzero schrieb:
> Hi!
>
> I'm currently testing a few Open Source WCMS Systems like OpenCms and
> Magnolia (Java based).
> All this WCMS using JSP's for Templates (together with a own Taglib) and
> Magnolia stores the Content
> in an JSR-170 Java Content Repository. I'm wondering if it is possible to
> integrate some Content
> from this Content Management System into a Tapestry Application. Goal would
> be that the user
> is able to modify content in the Content Management System (like writing an
> article or adding a picture)
> and this content could be then included in Tapestry. Is this in some way
> possible?
> One of the greatest problems is that Tapestry uses his own kind of templates
> and OpenCms and Magnolia the JSP ones.
> Do you think there is a way to integrate this two things?
>
> Maybe you could help me.
> Thank you in advance.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org