[ic] User created pages?

[Carl Bailey]

On Jul 6, 2009, at 5:56 PM, Marty Tennison wrote:

> I was wondering....
>
> What's the best approach to allowing (trusted) admin users to
> dynamically create pages that exist in the DB only?
>
> I'm looking for a way to...
>
> 1) Fill out a form (one of fields holds the page URL)
> 2) Have that URL accessible through interchange. (example:
> http://www.mystore.com/cgi-bin/store/some_new_page.html)
>
> This is for a FAQ section of our website and we add to it often.  So  
> we
> are  looking for a way to  make it easy to add new FAQ pages with  
> search
> engine friendly URL.
>
> Right now I have a script that creates an actionmap with the URL as  
> the
> action and I fire off a catalog reconfig after the DB update.  I'm
> wondering if there is a more elegant way to do this.
>
> Any thoughts?
>
> -- 
> -  - -- ----  ---------------------------- --- -- -   -
> Marty Tennison                     DripDepot.com
> web: www.dripdepot.com
> -  -- --- --------------------------------------- --- --



Marty,

Your action map is a good start, I think,

Suppose your url is http://mystore.com/cgi-bin/vlink/faq/105/where-did-I-leave-my-keys.html 
.
(In general use dashes instead of underscores to separate words in  
long page names for better SEO results).

Let your action map look up "105" in a database table, then fetch,  
massage and format all the relevant FAQ data to display on the page.   
Set mv_nextpage to something like faq.html where you can use the  
variables prepared by the actionmap, placing them in your desired page  
layout.  If 105 is not found, set mv_nextpage to something like "faq- 
not-found" and provide a smooth way to handle that error condition.

Now your trusted admin staff need only update the table of questions  
and answers, which they can do in the Admin UI.  There should be no  
need for a catalog reconfig with this sort of approach.

Regards,
Carl
. . . . . . . . . . . . . . . . . .
Carl Bailey
End Point Corp.
t: 919-323-8025
. . . . . . . . . . . . . . . . . .