AbleCommerce Shopping Cart Software

We've got static HTML/CSS pages from our designer for the home, category, product, cart, and checkout pages that we want to integrate into AC7. Mostly to achieve a table-less layout.

What are the best practices for doing this while retaining the ability to easily upgrade, etc?

I've been looking at the files under "Layouts" and it looks like that might be a logical place to start -- copying the .master file that is closest to what we need, modifying it, and then applying it to the necessary pages.

Looks like we would need to make sure that we retain the stock ids and classes so the ajax/js doesn't break? Anything else we should be aware of?

Thanks.

Hello Will,

Have you reviewed the information in the store customization guide.

ftp://ftp.ablecommerce.com/AC7_Docs/Abl ... 0Guide.pdf

It should answer your question.

I did read that. Are you saying we should do everything through scriptlets and controls?

FYI -- I was able to create a new layout scriptlet, but when I try to create a header or footer scriptlet, it creates the corresponding file in the file system, but the new scriptlet doesn't show up on the scriptlet list. Is there something I need to be doing to make header and footer scriptlets show up?

Hello Will,

I've not tried to customize AbleCommerce beyond what's in the customization guide, so I don't really have any advice beyond what's in there.

FYI -- I was able to create a new layout scriptlet, but when I try to create a header or footer scriptlet, it creates the corresponding file in the file system, but the new scriptlet doesn't show up on the scriptlet list. Is there something I need to be doing to make header and footer scriptlets show up?

The refresh cache routine was not looking deep enough in the directory structure to pickup the changes. The following patch will take care of the issue. Just drop it into the bin folder.

ftp://ftp.ablecommerce.com/patches/Able ... atch_1.zip

If you do not want to use the web based administration features with your site, like on screen page editing, you can go the route of making a custom .master file and applying it to your pages like a traditional .NET application. You still will want to make your pages inherit from CommerceBuilder.Web.UI.AbleCommercePage.

But what you are describing is the exact situation that "Layout" scriptlets were designed for. If you want to try using the scritplet framework, here's how:

1) Create a new theme for your design. In beta 2, you can get to the theme manager from Website -> Themes File Manager. From there you can copy one of the existing themes to a new name.

2) Replace the content of style.css with your own CSS.

3) Create a new layout scriptlet, paste in the contents of your static HTML. Replace the content areas of your static page with the layout tags (e.g. [[layout:Header]] and [[layout:Content]]) as discussed in the customization guide.

Let us know if you have questions or troubles with this process, it may point to something we need to provide more documentation or assistance with.

I would like to try and retain the web-based admin features. I went through steps 1 - 3. Makes sense so far.

However, once I go through that process, I end up with three wrapper tables around my header, content, and footer scriptlet content.

I want to get rid of these tables if I can.

Here's the code I get:

<table cellspacing="0" cellpadding="0" border="0" id="ctl00_ContentZone" style="width:100%;">
<tr><td style="height:100%;">

<table cellspacing="0" cellpadding="0" border="0" style="width:100%;height:100%;">
<tr><td>

<table cellspacing="0" cellpadding="0" border="0" id="WebPart_HomePage" style="width:100%;">
<tr><td>
<div id="ctl00_wpm_HomePage">

[Header Scriptlet Contents]
[Layout Scriptlet Contents]
[Footer Scriptlet Contents]

</div>
</td></tr>
</table>

</td></tr>
</table>

</td></tr>
</table>

[Webparts Panel Code]

I see. Those tables are generated by the Microsoft control that handles the "webpart" system. We use that as the basis of the scriptlets / on screen editor.

Is it necessary to remove those tables from the output to achieve your design?

I have just logged this as a bug to be addressed. I know of one way we could remove the table outputs when the page is not in "edit" mode, but I'm hoping I can think of something even more efficient.

When you are not in edit mode, it would be nice if these wrapper tables were not rendered to the browser.

I'm not sure if they will or not. The layouts we have are validated and tested outside of the system before we apply them.

I don't really want to send unnecessary editor-related HTML to the customer -- slows things down on all levels. There's no positives. We should strive to make the end HTML as high-quality as your backend code. Wrapper tables are antiquated these days anyways.

Aside from unnecessary bloat, the biggest practical problem I see is some browsers will only display a table's contents once every item has finished loading (including images). If the table is not present, the page components render as they are loaded. Makes the page appear faster.

Sometimes the Microsoft controls produce less than optimal output. It may require us to make a custom version of this control in order to clean up the html.

That would be great if it's not too much hassle.

I assume if I take those tables out it breaks the browser-based editing functionality?

The only way you can take the tables out is to remove the Webpart Editor Zone control that wraps the content of the page. Yes, that will disable on screen editing because it's that control that responds to the toggle between view and edit modes.

What I need to research is whether we can subclass that control and make a custom render that doesn't include the tables. We don't need that HTML for any particular purpose.

I think we can probably do without the web-based editing function. Been doing most of our custom work on the file system.

The web-based editor is great for figuring out how screens are assembled, though.

FYI, I have created a new Zone control that does not output all the extraneous tables. This is going through QA now, and assuming no problems are found, it will be part of final. With the new zone control, your output would be reduced to this:

<div id="ctl00_wpm_HomePage">

[Header Scriptlet Contents]
[Layout Scriptlet Contents]
[Footer Scriptlet Contents]

</div>

That's perfect. Thanks!

Logan Rhodehamel wrote:If you do not want to use the web based administration features with your site, like on screen page editing, you can go the route of making a custom .master file and applying it to your pages like a traditional .NET application. You still will want to make your pages inherit from CommerceBuilder.Web.UI.AbleCommercePage.

But what you are describing is the exact situation that "Layout" scriptlets were designed for. If you want to try using the scritplet framework, here's how:

1) Create a new theme for your design. In beta 2, you can get to the theme manager from Website -> Themes File Manager. From there you can copy one of the existing themes to a new name.

2) Replace the content of style.css with your own CSS.

3) Create a new layout scriptlet, paste in the contents of your static HTML. Replace the content areas of your static page with the layout tags (e.g. [[layout:Header]] and [[layout:Content]]) as discussed in the customization guide.

Let us know if you have questions or troubles with this process, it may point to something we need to provide more documentation or assistance with.

This process works great. The problem I get to is after we've created the new layout scriptlet, we then have to create an .aspx page on the file system that references the correct scriptlets. We end up with 2 files for each static page:

- 1 .aspx file to hold the <asp> tags -- placed where we want it in the file system

- 1 .htm file in /App_Data/Scriptlets/Custom/Content/

Is this true, or is there a different way to do this?

I demoed the web-based tools to our content managers, and they do not want to use the web-based editing tools.

Is there a way to create a single file for static content pages, edit it on the file system, and still be able to use ConLib and nVelocity tags?

Thanks,

Will