GlenB wrote:
> The biggest problem we face with
>something like a LAMP solution is how our ordering and billing system
>utilize separate customer and prospect/contact files for non-standard
>purposes. It's been tough, working directly with the data for eons
>now, trying to figure out a viable solution that offers B2B focused
>and B2C focused checkouts that merge to the billing process properly.
>I think I've resigned myself to the fact that I'm going to have to
>rewrite most of the ordering and billing system just for the sake of
>easy B2C ordering.
===
WARNING to Glen Batchelor:
Someone has stolen access to your PC and is posting unusually noobish
comments to public forums! I know these postings couldn't possibly
have come from you so please let us know when you have recovered your
equipment. Good luck. ;)
===
When working through a DAL and Business Logic Layer (BLL) the
front-end isn't concerned with how the server data is organized. So
the issue with prospect/contact files is unrelated to any front-end
interface, and therefore none of that is specific to LAMP or any other
stack.
> Each new individual that places one order with us takes up a new
>customer number and a contact account. Our entire system was
>originally written with a limited account number length and I'm afraid
>that with the continued growth we will hit the magic repeating 9
>series that grinds us to a halt. So, the answer is a consumer customer
>database that is not part of our original B2B center.
Personally I would look at this initially as a requirement for some
sort of XREF on the server, rather than a requirement for new database
structures. But sure it sounds like you're doomed for some back-end
re-work regardless of how the front-end is handled. Even with XREFs
where you can take any ABC and link it back to a 99997 in your
existing file, eventually you're going to run out of unique IDs.
>> I suggest this because you might get some other companies to help fund
>> the effort, and because these offerings are GPL, the code all goes
>> back to the OSS pool, so a lot of companies could benefit later on.
> Whatever we decide to do, we will be paying for it and it will be
>considered our IP due to branding, data, and internal technology that
>would be tightly integrated. If that is a breach of a specific license
>or contract then we'll move on to another solution.
I often have a hard time figuring out where the line is between
changes made to a core environment and site-specific customizations.
If I increase the size of a product description field am I improving
upon the core, thus invoking an obligation to publish my change? Or
do I need to create a module where the product description gets its
size spec from a remote source, then I publish that module and set the
description however I want with a disconnected, non-core, proprietary
piece of code. Heck, maybe I'm using some Nobel Prize winning
algorithm for computing optimal field sizes and I don't want to share
that as part of an eCommerce package. Apparently this is an ongoing
question with a lot of FLOSS developers because I've had many
discussions with people over the years about my responsibility for
sending code back to them and every discussion seems to result in a
different approach to solve the problem. In short - GPL might be very
clearly defined but it's very clearly interpreted by everyone
differently. But I digress...
>Our existing web
>functionality, business practices, and our pricing have given us
>atleast 20% yearly growth for the past 6 or so years. I really don't
>want to ruin that growth trend with a shotty OSS solution that hasn't
>been enterprise tested and approved. You know I'm all about OSS, but
>this specific scenario isn't a test bed. Web sales are over 50% of our
>yearly sales now and I can't play around with uncertain software.
We're in danger of changing roles here as I suspect you'd be taking my
position in a different discussion, and I yours. Nevertheless... I've
mentioned here before that there are a number of ERP packages that
have been open-sourced - not necessarily Free but arguably Libre and
somewhat maintained by cor****ate (=stable?) entities. A couple of
these are being taken quite seriously by a significant business
community. Point is that quality has improved out there in partial
response to market pressures, so it might be worth reconsidering your
OSS options.
One could consider this an inevitable evolutionary step. With so many
people working on OSS you'd think some real business software would
have to come out of the fray at some point. Picture: a million
monkeys and a typewriter and you'll get my drift. But I digress...
Too many Pick guys have the blinders on and think they can still
charge big bucks for ERP just because they consider the SAP and Oracle
Financials as competition, where companies are paying even bigger
bucks. In today's world the big guys are moving into the SMB market
because they've saturated the Fortune 5000's. Their pricing and
feature sets are being adjusted to accommodate the new target audience
- our back yard. These OSS ERP packages are the Bazaar's response to
the initiative of those Cathedrals, and it's self defence for some
developers who realize that the only way to beat the big cor****ations
may be to give the software away for free and generate revenue from
services. Given these trends, I'm confident some MV VARs will
inevitably hit the same wall they've been giving me for a while now:
"why should I buy my business software from you when I can download
something else for free?" But I digress...
>
>> I just helped another client with a PHP/D3 interface via FlashCONNECT.
>> This works well because the PHP guy doesn't know FC/D3 and the D3 guy
>> doesn't know PHP. The pipe is in place, and the developers just need
>> to work out an API for each new request type. When different requests
>> look similar, the API gets refactored to be more versatile.
>>
>
> I've considered such an approach to development and deployment, but
>I'm still limited by FlashCONNECTs inability to accept an XML post.
>MVWWW has taken a back bench to kids and work this year and it's still
>not done well in the proving grounds for public activity.
Skip the XML for now, it might be an unnecessary layer. If I need to
do XML with a PHP client I'll create a .NET web service to call MV
subroutines (5 minutes?) then generate a PHP class using the WSDL (1
minute?) and interface with that from standard PHP OOP. The XML can
be parsed in .NET (considering everything .NET does is based on XML
this is pretty fast) or the payload can be passed into MV. The point
here is that I'm not concerned about trans****ting XML, only processing
it at either end - and again only if I really need to.
>I have move
>forward a tad in the QMXML parser, though. I suppose I could resort to
>an HTML POST and dump an XML do***ent back to the client.
>Unfortunately, that means massaging data into a form POST and then
>extracting it in D3. I really don't want to have to deal with raw
>connectity at this level in the game.
Yup, I'm tired of that game too. That's why I'm not dinking with
D3CL, UO, QMClient, or anything else anymore. I've got a standard
pipe and now I just want to work on functionality. (Hey, that reminds
me, I need to send you the spec to my new MVFS which allows all MV
platforms to interoperate with each other and anything else using
plain ol paths and files. LOL) But I digress...
> My focus is a lot wider with
>this(company wide) and I'm not apposed to dropping FC for another
>connectivity package that will give me multi-dimensional access to my
>D3 data. MV.NET comes to mind, but I have to admit I don't know a lot
>about it in these terms.
That's why you have me bud. ;)
>> All sites I'm working on now require Ajax.
>
> AJAX would be nice for some aspects of the site, but keep in mind
>that we're a real B2B and B2C web site. Flash and glitter is nice, but
>it "doesn't feed the bulldog."
Don't confuse Ajax with glitz. For B2B/B2C the sizzle needs to be
kept to a minimum. I look at Ajax as being to the rest of the world
what IBM 3270 emulations are to Pick guys. We wouldn't dream of
making an end-user typing a full page of data into a green screen
before we give them a response, and peeps these days look sideways at
serious websites that have a submit button at the bottom of the page.
To many, Ajax is synonymous with Web 2.0. To people entering the work
force who have never even used a thick client for client/server, you
need immediate gratification from a browser form or they're going to
call it primitive. Within the last year the questions coming my way
aren't about thick or thin anymore. I get asked about minimizing
bandwidth and managing licenses - it's assumed that there's not going
to be any screen flicker or page-sized payloads. Whenever someone
asks me for new web work I ask them to point me to a site that does
something like what they want. Inevitably they point out an Ajax site
(regardless of the stack).
I confess so far my productivity has dropped and it takes me almost
twice as long to put together a fully functional Ajax page compared to
page-level processing. My biggest problem now is building toolkits to
minimize that pain - people expect field-level validation but there
ain't a soul alive that expects to pay twice as much for it.
"Knowledge" is the most im****tant tool in the kit and that tool gets
sharpened with every project. Anyway, I wouldn't recommend DesignBais
for your purposes, Glen, but one of the reasons I like it is that it's
Ajax from the get-go. But I digress...
>Whatever is implemented must be
>browseable by bots for organic search engine indexing.
I tend to think of such things in terms of "honey pots" - specific
pages get SEO because they're meant for bots. User data entry pages
shouldn't be scanned by bots - they just don't belong there. It's
relatively easy to separate these pages so that user pages don't get
indexed, and when a bot scans a honey pot, anyone linking back to the
page will get forwarded to a page that's more useful to a human being.
>I initially
>considering implementing AJAX with layers in the new filter
>specifications, so that you can filter the product listing without
>reloading the page. That's just one small facet of the entire project
>though. Most of the content will be search engine optimized with a
>parallel focus on visual design.
This last goal expresses objectives that are almost 180 degrees apart.
Visual design is for people, not bots. Bots gather information, not
visual layout - or rather, they "should"... When you click a link on
Google it's not because the target looks ***y, it's because it has
info you want - the glitz n glam come when the page loads, and they
are further tempered by who loaded the page and why they are there -
if one can get this sort of info.
>> So while you're considering whether to make or build solutions, I
>> encourage you to think about how existing solutions that almost fit
>> might be extended.
>
> That's what I need. A list of "existing solutions." If you have an
>existing e-commerce ****tal, then I'd be glad to demo it.
First step might be to google for "open source ERP" or check for "ERP"
on sourceforge. Aside from that, Nebula R&D does provide research as
a professional service. :) (Jus yankin, bud)
> The problem,
>as I told the president here, is that you won't find a "canned" e-
>commerce ****tal at any decent sized company. Every company runs their
>own way, which is normally driven by process. The few "canned" ****tals
>I've reviewed in the past couple of years lacked the real B2B features
>that we have to have for our large accounts. I can find a shopping
>cart program just about anywhere, but 99% of them are for mom-n-pop
>retail stores. Our requirements are a little unique and we're starting
>to experience growing pains.
No doubt - it might sound like I'm really pu****ng the OSS angle but I
honestly don't think you'll find what you need unless you're really
lucky. So why all the chatter? Because as time goes on we need less
luck than in the past to find complex solutions in FLOSSLand. I dunno
but I think it's worth some research.
>> Of course if you'd like custom ASP.NET work done or you find an
>> ASP.NET commerce site that you like (FLOSS isn't limited to PHP) then
>> let me know.
>>
>
> Can you point me to some examples?
Head over to http://asp.net
and search for "commerce" or similar
keywords. I know they have a ton of packages, but I don't think they
categorize them as free or for-fee. Some of the packages look
simplistic on the face but claim some remarkable clientele - maybe I'm
missing something. I don't have much time now but I'll try to think
about this as time permits. I'm sure we'll be talking about this
soon.
>> Best,
>> T
>>
>> Tony Gravagno
>> Nebula Research and Development
>> TG@[EMAIL PROTECTED]
remove.pleaseNebula-RnD.com
>> Nebula R&D sells mv.NET and DesignBais worldwide,
>> and provides related development and training services
|
