On another note, what do you all think about Workspaces being Package Manager or Package Management. I know that there will be future ability to assign different sets of packages to specific contexts but we could do something similar to the Topics as they relate to the Lexicon instead of separating by context. Or something like that.
Workspaces to me, while a friendly term has a nearly imperceptible relationship with packages etc. I think we can spare a few characters in the lexicon for that.
If "Workspaces" is tied into the core can it be decoupled or translated in the lexicon for users and otherwise refered to in the API. Again it will only matter to the English speaking devs all others will likely see different words to represent the term.
MODX Staff
MODX Staff
MODX Staff
IMHO the concepts need to match what we call it; can you imagine if we didn’t understand what the marketing group was talking about when they wanted new features? It is absolutely imperative that we do not dumb down the technical concepts of the core product, or the chasms between developer, designer and end-user will continue to increase. It is for component developers to come up with the end-user solutions; presenting bulletproof interfaces and tools for specific requirements that requires little or no technical knowledge of the framework.
This is an honest question as I don’t have any answer or opinion but is it entirely necessary to have the terms of the elements match classes and functions/methods/objects in the core or could they not be assigned in the lexicon (a term that has grown on me) and be different in the manager and the API? They’ll only be the same in english any how so I wonder if they need to be tethered?
Just ignore Workspaces for now -- a workspace is a specific core version + configurations + core extensions + packages + lexicons + etc. -- it’s simply a way to isolate and quickly switch the entire core engine. This will be invaluable for upgrades, working with development/staging/prod environments, etc. But for now, a "Core Workspace" is simply the core/ directory which you are working with. I really don’t want to argue about the names anymore in this regard. I’ve chosen these names for very specific reasons, and until I am able to fully explain and document this vision, I think it’s counterproductive to do anything but try and understand the concepts. Once we understand and can discuss the concepts in full detail, then we can consider changing how we refer to these.
If "Workspaces" is tied into the core can it be decoupled or translated in the lexicon for users and otherwise refered to in the API. Again it will only matter to the English speaking devs all others will likely see different words to represent the term.
MODX Staff
It’s kind of accurate -- your understanding is still cursory, but I think you are really getting closer to comprehending it. Let’s be patient, continue to discuss these concepts and the trouble everyone has understanding them, and give Shaun and I time to better document all of this in the glossary and create a few visual diagrams to help solidify the concepts without reverting to oversimplification. These exercises are invaluable to Revolution’s ultimate success, so thanks everyone for keeping up their passion and doing everything you can to understand the additional complexities that it brings to the table.
As a follow-up to my earlier description, here it is with Vehicle substituted and slightly edited for increased clarity. Is it accurate?
MODX Staff
MODX Staff
I simply don’t agree. This leads to developers not accounting for the things that having Workspaces will affect down the road, making it harder to implement and further reducing adoption. It truly makes no sense to keep anything "behind the scenes" in this framework, IMHO. It makes much more sense to me to attempt to explain and train, and to do so in context of who you are (i.e. developer, designer, content editor, etc.). This will lead to natural improvements in features, functionality, and understanding between the various stakeholders interested in working with MODx, before the code is even written (which is the major complication with this entire discourse, which should have take place more than a year ago when 0.9.7 was first being developed).
If Workspaces are purely behind the scenes for now then let’s keep them out of the picture and introduce them at the appropriate time.
MODX Staff
It is absolutely imperative that we do not dumb down the technical concepts of the core product, or the chasms between developer, designer and end-user will continue to increase.
It is for component developers to come up with the end-user solutions; presenting bulletproof interfaces and tools for specific requirements that requires little or no technical knowledge of the framework.
) will think your description above is more accurate if you change:each comprised of an Object and optional Resolvers/Validators that make sure things go as planned.
each comprising an Object and optional Resolvers/Validators that make sure things go as planned.
or
each consisting of an Object and optional Resolvers/Validators that make sure things go as planned.
(I’d recommend the latter.)
