You are viewing an historical archive of past issues. Please report new issues to the appropriate project issue tracker on GitHub.

Feature request #1331: Product pages

Kind feature request
Product wincent.dev
When Created , updated
Status closed
Reporter Greg Hurrell
Tags no tags

Description

At the moment we have an uncomfortable divide between two parts of the site:

I need to bring the product pages over to the new site; that, and the store/purchase pages, are the biggest remaining pieces for the migration to be considered basically complete.

One of the roadblocks so far has been that I haven't been sure how to conceptualize or model the product pages.

Basically, I can't treat them like wiki pages because they need to be visually distinct. Mere wikitext is not going to be enough; as I'll want to use complex CSS, HTML and possible JavaScript to make an attractive presentation of each product.

But I do require these pages to be relatively integrated with the new site, so I can't just hand-code HTML and upload it.

This is a double-edged sword because neither do I want to be cutting and pasting large slabs of HTML in a browser-based admin interface. Clearly the number of product pages has to be very low, conciseness will be of the utmost virtue.

The other question is how will the help documentation be integrated into the site? That will and must be static HTML because it gets distributed with the applications (or should I challenge even that assumption and just default to online help?).

Will the product namespace become kind of like a secondary wiki? Should I be looking at displacing as many pages as possible into the wiki namespace? Do I need proper namespacing in the wiki itself? (ie. Synergy::Preferences, Synergy::Preferences::Generaland the like?)

So I'm opening this ticket as a kind of scratch pad for "thinking out loud" and brainstorming these issues through.

Comments

  1. Greg Hurrell

    Ok, on thinking about this for a while the design I currently have in mind is as follows:

    First up, we'll be adding a Page model. Products will "have many" pages. (In reality we're talking about an "index" page, "buy" page, "download" page, "FAQ/Support" page and little else.)

    The Page model is really just a simple container for arbitrary HTML data. It will "belong to" the parent Product model. One page for each product will have it's default attribute set, indicating that it should be shown when no other page is specifically requested (ie. this is the "index" page).

    The content will be arbitrary HTML, and possibly inline JavaScript if required to implement effects (the classic "lightbox" effect, but without the black background). Content will be basically static, infrequently updated, so the pain of pasting into a browser won't have to be suffered too often. In the event that dynamic content be needed I could consider using ERB instead of pure HTML, but we'll cross that bridge when and if we come to it.

    I'll need to think about how to preview this stuff because ideally I'll want to do at least the initial mockups as static HTML pages.

    I'll have special CSS in a products.css file that is included for all actions in the ProductsController. The HTML should be very clean (headings, paragraphs, lists, img tags), with maximum use of CSS so that the visuals can be easily controlled for all products at once.

    A common JavaScript page, products.js may also be included if the need arises (lightbox functions etc).

    Images, at least for now, will be manually uploaded to a static assets directory. Later could consider adding an interface for it.

    The Product model will have two more fields added, header and footer, containing arbitrary HTML to be shown above and below each page.

    Design principles:

    • pages should be attractive
    • pages should be short

    Some notes on what this isn't:

    • we store stuff in the database rather than as templates in the application source code because we don't want to have to do deployments just to update the product pages
    • we store stuff in the database rather than as files on disk because we want this to be editable from anywhere without the use of an SFTP client
  2. Greg Hurrell

    Thinking more about the idea of running the HTML through ERB first (seeing as the pages will be cached and speed is not an issue), was trying to think of use cases.

    About the nicest used for this would be to be able to use [[wiki link markup]] like this: 

    ... with <%= "[[Mac OS X]]".w %> or above ...

    But that would actually work because all wikitext output is wrapped, at least, in <p></p> (or similar block-level) tags: 

    ... with <p><a href="/wiki/Mac_OS_X">Mac OS X</a></p>
or above ...

    So for inline styling it simply wouldn't work and it's debatable that typing ERB tags and the wikitext markup would be much easier than just typing the HTML in the first place.

    A more tempting use case is for using path helpers:

    ... more information in <%= link_to 'the forums', forums_path %>.

    Instead of typing:

    ... more information in <a href="/forums">the forums</a>.

    Although that too, isn't all that convincing.

    One place where wikitext markup would work would be when using it for entire paragraphs: 

    ... and all that.

<%= %q{This is a slab of [[wikitext]]
which can have [/forums links] and
all kinds of other stuff in it.}.w%>

And by the way ...

    But even that is not all that convincing.

  3. Greg Hurrell

    Thinking about how I am going to do the routing here.

    With the standard products resource which "has many" pages, you wind up with URLs like:

    • /products/foo (to show product "foo")
    • /products/foo/pages/welcome (to show the "welcome" page of product "foo")

    But I think I'd prefer to have URLs like:

    • /products/foo/welcome (to show the "welcome" page for "foo")

    As far as I know I can't do this using the standard RESTful :has_many helper in config/routes.rb.

    Might have to add a separate route like:

    map.product_pages '/products/:product_id/:page_id', :controller => 'products', :action => 'show', :protocol => 'https'

    (Note that I could let this be handled by the PagesController, but to the user the page content looks embedded in the product pages and doesn't actually look like a separate resource at all, so that's why we let this be handled by the ProductsController.)

    Not sure if it will work, but that's the general idea.

  4. Greg Hurrell

    Ok, the backend for this is basically down now.

    I can view products, create, edit, delete pages etc. Now I just need to start porting over the content from the old site.

  5. Greg Hurrell

    This is a blocker for ticket #1314.

  6. Greg Hurrell

    This is pretty much done and deployed now. It's been in use with the new Synergy product pages for some time, and it has worked out quite well. Will mark as closed.

  7. Greg Hurrell

    Status changed:

    • From: new
    • To: closed
Add a comment

Comments are now closed for this issue.

Menu