Hi Florian
Yes, changing to a hierarchically organised storage system (compared to
a rdbms) needs some re-thinking. I would indeed spend time on that. The
new technology offers tremendous possibilities!
You are right too, documentation would be nice... but find someone who
volounteers, and has the skills to write in a way, which is very logic
and understandable...
But I have another suggestion: Visit the four-day-developer training!
Not only you are "forced" to think about the repository, you will also
do a lot of exercises around it! Check out
http://www.magnolia.info/en/magnolia/services/training.html for more
information
/Giancarlo
(Florian Fuchs) wrote:
Yes you are absolutly right, as I wrote first, my solution is quite
dirty (simple, but not as it was meant by magnolia/jsr170)
In the next days, I will try to do something comfortable to manage
simple images, with storage in the repository.
Got to think about that a bit.. :)
Giancarlo, Thanks for your advise, didn't think of several points.
Regards,
Florian
P.S: Please, would someone document things like that, just solution
hints, so no one would think about storing some content in the
filesystem :)
On 12/6/05, user-list@magnolia.info <user-list@magnolia.info> wrote:
(Giancarlo F. Berner) wrote:
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
I think I have managed to even get around caching woes on my
implementation. My file manage does something very similar to yours....
I basically grabbed the mechanism which stores an image/file to a web
page in a paragraph and then wrote a class which inserts all my
images/files to one page in my website repository. I call this page
"upload" and have created a template for it which doesn't allow any
editing. It just displays the files which are in it for the authors and
an invalid request to a user. Then on the back side I wrote a new tab
for the admin console which lets authors add/delete files and a custom
control for them to select images from a dialog and insert them into
paragraphs. When an author adds a file the upload page needs to be
activated to push the files to the public instance as expected. The
cache manager is also able to cache these files because they are stored
in exactly the same way that Magnolia's default file control inserts them.
--
Adam Cooper
Talisen Technologies
E: [EMAIL PROTECTED]
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
