MODX Staff
Dang, wish I would have gotten this before I made a screencast. Yeah, that’s a good suggestion. Mind JIRA’ing it?
On the package builder process, I’d still like to make the build script (which is now the user-interface for package building, since the GUI is out). I do have one suggestion and some more ideas. One is trivial: Change $builder->create() to $builder->createPackage().
I can live with “vehicle” and haven’t been able to come up with anything better since my replacement ideas won’t work. I’d still like to do something about “resolver” though. It’s such a general term that it could have been used as the name for a package, or a vehicle, or a lot of other things in MODx. I thought of “passenger” which still isn’t great but might be better since the user can imagine a passenger with a bundle of files in his or her lap or a set of instructions to follow when the vehicle arrives.
In another approach, if the resolver object could be a member of package instead of vehicle, I think it might be possible to hide it from the user as I suggested before, but that may not be feasible.Unfortunately, it cannot - resolvers have to be attached to vehicles, as different vehicles might handle resolvers differently. Users won’t really see resolvers anyway - only developers making the packages will.
Dang, wish I would have gotten this before I made a screencast. Yeah, that’s a good suggestion. Mind JIRA’ing it?
On the package builder process, I’d still like to make the build script (which is now the user-interface for package building, since the GUI is out). I do have one suggestion and some more ideas. One is trivial: Change $builder->create() to $builder->createPackage().
MODX Staff
There are two special features available in vehicles, both of which can be "passengers" so to speak, though they are all scripts (think of file resolvers as PHP resolvers already coded to handle the job of copying files into place):
PPS: I was thinking that passengers could "carry" files to install when the vehicle arrives, but they could also carry sets of instructions (i.e. scripts) that they execute on arrival. And there’s no question that the word "passenger" has a closer association with "vehicle." It makes sense that "passengers" need to be attached to "vehicles," something I was slow to grasp about "resolvers."
Quote from: BobRay at Oct 02, 2008, 07:37 PM[*] Vehicle Validators - these are evaluated after an object is deserialized, or "loaded", from the vehicle, but before anything else is done with it; returning false from a validator will stop any further processing of the object.
PPS: I was thinking that passengers could "carry" files to install when the vehicle arrives, but they could also carry sets of instructions (i.e. scripts) that they execute on arrival. And there’s no question that the word "passenger" has a closer association with "vehicle." It makes sense that "passengers" need to be attached to "vehicles," something I was slow to grasp about "resolvers."
[*] Vehicle Resolvers - these are evaluated after the object has been processed (i.e. inserted, updated, etc.), even if the object already exists and optional attributes indicate it should not be updated.
Does that help better clarify their meaning?
Resolver - vt.
To make a firm decision about.
To cause (a person) to reach a decision. See synonyms at decide.
To decide or express by formal vote.
To change or convert: My resentment resolved itself into resignation.
To find a solution to; solve. See synonyms at solve.
To remove or dispel (doubts).
To bring to a usually successful conclusion: resolve a conflict.
Medicine. To cause reduction of (an inflammation, for example).
Music. To cause (a tone or chord) to progress from dissonance to consonance.
Chemistry. To separate (an optically inactive compound or mixture) into its optically active constituents.
To render parts of (an image) visible and distinct.
Mathematics. To separate (a vector, for example) into coordinate components.
To melt or dissolve (something).
Archaic. To separate (something) into constituent parts.
MODX Staff
To bring to a usually successful conclusion: resolve a conflict.
MODX Staff
Does that by extension then imply that Resolvers are associated with something some consider a negative: conflict or a problem or a sticky situation?
Hmm, IMO, Resolver is the most concise term for the generic concept. This definition nails it for me:
To bring to a usually successful conclusion: resolve a conflict.
MODX Staff
No, it implies that it will "resolve" any potential problems (i.e. missing files or dependent data records, or whatever). We could call them Harvey Keitels or the Wolves, or maybe the "Cleaners", but I thought resolution was a more neutral approach.
Does that by extension then imply that Resolvers are associated with something some consider a negative: conflict or a problem or a sticky situation?
A Vehicle is a container which holds an object inside a Transport Package. Think of them as vans being pulled into a cargo hull, each containing an important member of a team (each full of validation and resolve) which can be intelligently deployed when it arrives at it’s destination.
Also for the benefit of others that might be reading this cold, would a definition of what a "Vehicle" is in the first place and how they’re used possibly be beneficial?
Just a thought: If "passenger" isn’t a good choice (and I think it has its problems too), maybe we could replace "resolver" with several entities like "VehicleValidator," "VehicleFileTransport" and "VehicleScriptTransport" (fileCarrier?, fileMover?) in the front end (by which I mean the build script). It’s much more obvious what those would do.This principal seems to make sense to me (if the name could say as much as possible it helps to understand). I don’t really know what you are discussing, but when I read something like "VehicleFileTransport" it seems to make sense to me. I guess that you need to ask if this needs to make sense to more advanced coders or to the general coding public (like jQuery vs MooTools). Anyway I may be way off
