Oops!
I have been removing a lot of arguments in this post.
Ok seem right to me explain, because I asked the question:
whether "MODx Cloud" will replace a "MODx Revo".
In our office we are working on a project of abstraction of the "core MODx" to allow,
the control objects and the data objects, can be managed from the MODx panel.
Thus allowing that "MODx" control the flow of all our services
so you can administer all layers of management of our
platforms (end user, operator, administrator, owner, snmp, rest, etc).
What today we call in our group, "The Jungle" (Jungle of services), in a few months
should be an ordered structure of control.
And our choice would lead us to "MODx". that since some years, we use,
as a simple content manager only for our "end users".
Why MODx?
By cleaning up your code, for the modular structure of its classes and especially
the orientation of a significant number of professionals using MODx.
Initially thought to provide the appropriate revisions to integrate MODx
amicably with our other services (CXF and panels in java).
But to our surprise, reading the code of "MODx" we understood that
the MODx team, has done an extraordinary job.
So We have asked ourselves,
why not do just one layer of abstraction?
Why not allow that our Java objects, are created or modified from the MODx Control Panel?
Why not allow for creating components, in other programming languages or other "UI frameworks", from the same panel?
With this type of structure could peacefully integrate objects of all types
without having to play the composition of the core.
It could have a panel creation of elements, developed in ZK, and others in jQuery,
mootools or whatever one chooses without removing benefits MODx,
so creating CMPs is simple, as long as one is capable of doing them.
And thus our only concern is to do something based on a system
that will be declared obsolete in a few months. But if this will not Occur,
...MODx is our best ally.
And as a last response to:
Quote from: splittingred at Jun 13, 2012, 07:28 AM
We're also open to ideas from the community as well.
I do not know if, upon completion of our project of abstraction, this may be easily integrated into the core as a component or patch MODx precisely because, in the politics of MODx, there are many rules about how a component should be ready for use in the community, (seems to be on a mailing list of netBSD
)but surely the linked approach of looking at the MODx component, ready as an abstract object provides the core, is very realistic and in many success projects, is this abstraction that makes, the powerful and versatile product.
Regards
