[UPHPU] Is PHP the right language for my project?
cole at colejoplin.com
cole at colejoplin.com
Tue Apr 8 09:08:31 MDT 2008
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 <chriswoodut at gmail.com>:
> 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?
> 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
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.
More information about the UPHPU