The comments about using the language your team knows is very appropriate, as long as it meets all your business needs. It's been my experience that off-the-shelf solutions work only if your business isn't very specialized. Once the off-the-shelf hits that "this system doesn't do that", the top brass will flip out. Again, it's about hitting ALL the business needs.

Quoting Chris Wood <[EMAIL PROTECTED]>:

There is a lot of metadata for each widget and some in multiple languages.

If this is a client-side widget, it would be interesting to know how you keep your metadata. Is it a client-side db? A local text file? SQLite?

This system will need to generate purchase orders to vendors and track the
kits (group of widgets) that each customer may be purchasing.  The system
would inventory the widgets.  This is a lot like a process-flow system and
an inventory type system that is very unique to our situation.

Do you want to keep your existing backend DB? Or is this going to be rebuilt for the web?

I think typically this would be done in a client-server environment like
c++, visual basic, .net, etc.  However, the customer facing portion of it
will need to be browser-based since they will be remote to us (around the
world).

I have done plenty of client/server apps that did online communications just fine. With those, it's a question of being likely tied to the desktop OS. For cross-platform, that would give you a Java app or a Flex AIR app possibility. BTW, the AIR runtime supports local SQLite databases. The nice thing about this solution is that the person can do work, make orders, without being online. When they finally have a connection, they can just upload all the data.

If it's the browser, which doesn't require any install, any of the traditional web languages should be fine -- really. AJAX is okay, and so is a Flex web app. I think the key here is your widget metadata, and how you get it to the database. You could upload a binary file, and have it parsed on the server (again, practically any language).

As you said, this is a process-flow system. The back end is easy to predict, and has plenty of viable options. It's what you need on the customer's front end of that widget data flow that should determine what you do there.

-- Cole






_______________________________________________

UPHPU mailing list
[email protected]
http://uphpu.org/mailman/listinfo/uphpu
IRC: #uphpu on irc.freenode.net

Reply via email to