Josh
that looks pretty cool and definitely is a valid way of tackling it.
May I encourage you to find the time to write a blog about it to share
some more details of what you did and how you achieved your goals?
I would also be delighted if you can submit this nice Magnolia
reference with some details using our new reference submission system:
http://www.magnolia.info/home/customers/references.html
Thanks!
All the best
- Boris
On Aug 1, 2008, at 11:43 PM, joshua portway wrote:
Boris,
I suspect what Vincent means is that most web shops don't want to
look like databases - by entering all of the data for products into
data nodes you end up being forced to make very standardised pages,
and if a particular product needs a special note, or you wan to show
an image of it in use etc. then that needs to be encoded into your
data schema. The pharmaceutical company website you point out
obviously isn't in that kind of market, and the database style suits
it well - not everything is like that.
I recently worked on a shop-like site where we used the alternative
approach of giving every product its own page ( http://www.mandarinStoneFrance.com
). Details about the product were stored on the page node and could
be edited by clicking a page property editing button at the top of
the page, or by editing certain fixed page elements, and then most
of the actual page itself was generated from the template reading
those properties. Because all the essential information (product
image, price, basic features etc. were stored on the page node
itself we could still treat the pages as data nodes and query them
to show lists of products etc.. However, the product page was still
a normal page, which allowed the web site owner to customise it by
adding extra text and image paragraphs to the standard template if
they want - they could also use all the normal magnolia tools for
laying out the page etc. This gave us the best of both worlds by
having the flexibility of a CMS to design product pages, and yet the
power of a data driven site for doing things like searches, product
lists etc. We also found that from a user experience point of view
the owner of the site found it much more natural to enter
information about products on the product page itself because it was
much more WYSIWYG than entering data into dry forms.
Josh
On 1 Aug 2008, at 18:11, Boris Kraft wrote:
Vincent
I am not sure why you think so. The data module uses the same
mechanisms we use anywhere else, specifically, the dialogs and
controls you can use in the data module are the same as in the web
repository. In other words, you can have a product detail dialog in
the data module that contains all the rich and nice-looking details
you wish to have. Once it is in there, you can use either search
queries to retrieve matches or simply link to products in a more
static sense.
By the way, this is something we did for the new magnolia.info
site, where we defined a "text-block" in the data module which
then can be referenced from other pages. In particular, we do this
for the news section, where each press release shows an "about
Magnolia" block to the right of the release. This allows us to
reuse this info anywhere on the site, and maintain it in a single
place, independently of the actual site structure.
For another example of this functionality, look at http://www.mepha.com/international/en/products.html
where we use the data module with the scheduler to import data
from an SAP system, augment it using Magnolia's end user dialogs
and finally render it dynamically with a multi-step advanced-search
implementation. (for an example of the latter, select "Anti-
malarials" from therapeutic area, and you will get a second set of
search constraints)
Cheers
Boris
On Jul 6, 2008, at 5:10 PM, Vincent F. wrote:
Hi,
Personally I would use data module only for storing commercial
details (price, stock quantity) and orders. Relying only on the
data and dms modules would make difficult to compose rich and nice-
looking product pages.
Vincent
- Relying heavily on the data module (and the dms module for
images)
- Implementing controller classes and beans to minimize the
amount of scriptlets in the JSPs
- Creating custom magnolia dialogs for the data management (of
course importers would be nice too)
- And also implementing one default set of shop pages (JSPs) to
have the module work "out of the box"
Did this answer your question or did I misunderstand you?
-will
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/
----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/
----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/
----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/
----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/
----------------------------------------------------------------
