I absolutely agree :-)
Magnolia does not offer something like a "Digital Asset Management"
application (yet).
What I do is put all reusable content (e.g. images) into some nodes
under "Config". Then I wrote a small dialog-control-class, which lists
all child-nodes from the given path (plus images) and the author can
select an image. What I store is the node-path to that image. So
whenever I want to change that image, all the other web pages
referencing that image are updated "automatically". So not a big deal,
except for caching...
If an image is changed in e.g. /Config/myimages/niceimages, that's fine,
cache is flushed. But the cache of the pages referencing that image is
not flushed! So you would have to find all handles referencing that
image and flush their cache. Such a "Cache-Dependency-Manager" would be
a nice feature as well.
So once the cache-flushing of pages with references to other content
pages is solved, building a DAM is not to complex anymore.
/Giancarlo
(Adam Cooper) wrote:
(Giancarlo F. Berner) wrote:
Hi Florian
Let me ask you a shy question: Why have you selected Magnolia?
I'm sure not only for the GUI, but especially because of the
underlaying JSR 170 compliant Content Repository!
Please keep in mind that your access to the repository is simply
through the repository's API. That in fact is the main purpose for
choosing a JSR 170 compliant CMS. Your JSP's don't worry about the
persistent storage, since that's taken care of by the repository
(through configuration). All your JSP does is read the content (also
binary content like images). To store content you preferably will use
the dialogs and let the authors do that. The repository (through it's
API) offers you additional "services" (like access control,
versioning, etc.), which enhances a data source to a content repository.
Please take a little time and check out the examples provided with
Magnolia. E.g., create a new web page based on the "Magnolia: Two
column Template". Then request the page and add a new paragraph of
type "Text and Image". Once you see how authors can add images, go
and look at the according JSP. That's a simple and common way to
start with. Additionally you can use standard Java classes to do
image processing, like resizing, etc.
hth
/Giancarlo
(Florian Fuchs) wrote:
He is probably thinking ahead to the situation where you have an image
that is attached to 10 different pages... if you have to track down
all 10 and manually change them then it can quickly become a
maintenance nightmare. Not to mention on the extreme scale where
having all these duplicates could cause size to become a problem.
Magnolia CMS doesn't really offer a good solution in this respect. In
fact that I would go so far as to say that Magnolia is seriously
lacking in the "store an image once and use it multiple places"
department. I ended up having to write my own file manager which uses
the JCR and exposes the resources as URLs to give my authors a common
place to put/update files.
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
