<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: E-Commerce Framework Part 2</title>
	<atom:link href="http://blog.digitalstruct.com/2007/08/02/e-commerce-framework-part-2/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.digitalstruct.com/2007/08/02/e-commerce-framework-part-2/</link>
	<description>Getting inside the mind of a php developer.</description>
	<lastBuildDate>Mon, 08 Mar 2010 15:25:11 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Steve W</title>
		<link>http://blog.digitalstruct.com/2007/08/02/e-commerce-framework-part-2/comment-page-1/#comment-23647</link>
		<dc:creator>Steve W</dc:creator>
		<pubDate>Thu, 04 Oct 2007 14:19:53 +0000</pubDate>
		<guid isPermaLink="false">http://blog.digitalstruct.com/2007/08/02/e-commerce-framework-part-2/#comment-23647</guid>
		<description>I&#039;ve been noticing the need for something like this for years.  I&#039;d be interested in helping out with the payment processing portion of this project.  What I need for the e-commerce projects I develop is a single interface to a sub-system that can handle multiple payment methods.  The component should be portable enough to be plugged into any custom php e-commerce application, but flexible enough to meet the checkout and configuration needs of any new shopping cart. 

Is work already being done on a similar payment processor?  How can I get involved?</description>
		<content:encoded><![CDATA[<p>I&#8217;ve been noticing the need for something like this for years.  I&#8217;d be interested in helping out with the payment processing portion of this project.  What I need for the e-commerce projects I develop is a single interface to a sub-system that can handle multiple payment methods.  The component should be portable enough to be plugged into any custom php e-commerce application, but flexible enough to meet the checkout and configuration needs of any new shopping cart. </p>
<p>Is work already being done on a similar payment processor?  How can I get involved?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stevan  Goode</title>
		<link>http://blog.digitalstruct.com/2007/08/02/e-commerce-framework-part-2/comment-page-1/#comment-13306</link>
		<dc:creator>Stevan  Goode</dc:creator>
		<pubDate>Sun, 05 Aug 2007 08:11:03 +0000</pubDate>
		<guid isPermaLink="false">http://blog.digitalstruct.com/2007/08/02/e-commerce-framework-part-2/#comment-13306</guid>
		<description>Once again I point out the project I&#039;m working on. Spurred into action by your previous post, I should have a more proper release out later this week.

It has some of the things in it that you have pointed out here, and some of the rest I had already decided to put in at a later point (honest!)

Take a look, and let me know what you think.... version 0.2 will be better.</description>
		<content:encoded><![CDATA[<p>Once again I point out the project I&#8217;m working on. Spurred into action by your previous post, I should have a more proper release out later this week.</p>
<p>It has some of the things in it that you have pointed out here, and some of the rest I had already decided to put in at a later point (honest!)</p>
<p>Take a look, and let me know what you think&#8230;. version 0.2 will be better.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike Willbanks</title>
		<link>http://blog.digitalstruct.com/2007/08/02/e-commerce-framework-part-2/comment-page-1/#comment-13059</link>
		<dc:creator>Mike Willbanks</dc:creator>
		<pubDate>Fri, 03 Aug 2007 15:09:02 +0000</pubDate>
		<guid isPermaLink="false">http://blog.digitalstruct.com/2007/08/02/e-commerce-framework-part-2/#comment-13059</guid>
		<description>&lt;blockquote&gt;The issue with business framework is that they have to match the business processes. And almost no company want that for their core activities or the other ones.&lt;/blockquote&gt;

This is primarily the reason to keep it technical.  For instance if you look at the layout it would provide baseline functionality that would allow for easy extensibility.  Business logic is not truly implemented but the core functionality that would allow for business to implement based on an OOP pattern to be more simplistic.

If we are looking at this from a developers perspective, there are components that are easily pluggable to implement certain types of things.  I continue to feel this is mostly the payment and courier support that is by far the most important.

What a business would then do is utilize the components to give them a base and then extend and build in their requirements.</description>
		<content:encoded><![CDATA[<blockquote><p>The issue with business framework is that they have to match the business processes. And almost no company want that for their core activities or the other ones.</p></blockquote>
<p>This is primarily the reason to keep it technical.  For instance if you look at the layout it would provide baseline functionality that would allow for easy extensibility.  Business logic is not truly implemented but the core functionality that would allow for business to implement based on an OOP pattern to be more simplistic.</p>
<p>If we are looking at this from a developers perspective, there are components that are easily pluggable to implement certain types of things.  I continue to feel this is mostly the payment and courier support that is by far the most important.</p>
<p>What a business would then do is utilize the components to give them a base and then extend and build in their requirements.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
