David E Jones wrote:
As you mentioned, yes, there *are* various commercial vendors doing
this, but no open source has this capability.
I'd be interested to hear more of what you had in mind for "this
capability".
The ability to customize anything and everything in the application
at a higher level than Java and XML.
Consider a small-medium business that has an ERP system, and one day
decides that they want to get a CRM system to track their sales force.
Which would be the best scenario of those?
(A) - A typical CRM implementation with data migration/integration work,
user training, More systems to support.
-OR-
(B) - A small CRM implementation with no data migration/integration, not
much user training, no more systems to support.
You've lost me a bit here.... It is definitely nice to avoid things like
data migration and integration and user training and support of systems.
I certainly didn't mean that scenario (B) will make the costs Zero. I
meant that with the second system -- CRM -- there will be much less
work to do outside of the implementation of the CRM itself.
What do you mean by 'start looking at data modeling'?
What I mean is actually designing how to store information for things
like products, orders, invoices, payments, shipments,
customers/employees/suppliers/etc, quotes, requests, and so on.
Well, thats already done. I have looked at how exactly to model and
extend several business scenarios. Remember, in my first post I
mentioned:
Note, The project has a working codebase.
Or is your intent to just create a framework and not get into business
level artifacts? Don't read too much into that question: that's a very
common and valid approach and I don't mean to suggest that you should if
it's not your intent.
Remember, in my first post I mentioned:
There is also an incomplete CRM-like implementation.
It *is* my intent to build several apps on top of this framework, to
make is easier to implement. That is what I think that this project
could benefit from OFBiz.
Are you still skeptical about using database to store application
objects? Consider moving the component-load.xml file to the database
and having a load-on-demand button somewhere. How much easier would it
be for users to activate/deactivate/upgrade components? and no downtime!
This would be exactly like Drupal's Module management system.
I am still skeptical about it, yes. It definitely sounds nice at first,
but I've been through cost/benefit comparisons for doing this with all
sorts of different types of data and even tried a number of these
things. Some things just seem to work better in files and other things
seem to work better in database records.
Perhaps more details into how this framework does things would help
convince you??
I think you're looking at going in the same direction that we are with
OFBiz. That's a great thing to see even if, or rather especially if, the
approach for getting there is very different.
Yup, same direction.
I'm trying to propose a different approach to doing things that IMO
would be much easier than OFBiz. If you're not sure that the approach
itself would be able to deliver the same functionality, then we need to
discuss that before getting into which is best.
Regards,
Ahmad
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
