Adding #baselines?
Locked
 
|
Hi Dale. I know that baselines inside Metacello are like versions, but what about adding #baselines in MetacelloProject. So that we can query like this:
ConfigurationOfXXX versions. ConfigurationOfXXX baselines. The problem is not just implementing #baselines but also that #versions is now answering also the baselines. What do you think? Cheers -- Mariano http://marianopeck.wordpress.com |
|
|
Mariano,
I think that it sounds like you are starting to do something that is in parallel with what Alexandre and I are doing with MetacelloBrowser, so I am wondering if if MetacelloProject is the right place... I agree that versions and baselines are good abstractions to have for the tools. Here's the full hierarchy of model classes that we're using for MetacelloBrowser: MBInfo MBAbstractInfoList MBAbstractVersionInfo MBBaselineInfo MBVersionInfo MBConfigurationInfo MBLabelInfo MBSpecInfo MBAbstractPackageInfo MBPackageInfo MBProjectInfo MBGroupInfo I don't mind adding protocol, but when you talk about 'baseline' as being something distinguished from a 'version', then I start thinking that you are trying to overlay a different model on top of the existing MetacelloProject/Spec universe and that an explicit model may be a better way to go ... The MBInfo hierarchy is meant to model the _conventions_ that we are currently using in Metacello so I am much more comfortable adding #baselines and #versions methods to MBConfigurationInfo (which wraps the MetacelloProject and configuration class) and as a matter fact they already exist:) It might make a lot of sense to pull the "convention model" into Metacello proper to make it possible for other projects to write code against the convention ... So that's what I think...what do you think?:) Dale On Apr 9, 2011, at 10:43 AM, Mariano Martinez Peck wrote: Hi Dale. I know that baselines inside Metacello are like versions, but what about adding #baselines in MetacelloProject. So that we can query like this: |
|
|
On Sat, Apr 9, 2011 at 9:42 PM, Dale Henrichs <[hidden email]> wrote:
No, in fact, I have never used MetacelloBrowser...I always do stuff by hand and one of the things I like for Metacello configurations as classes (instead of having XML!!) is that I can query them. So...I usually ask #groups, #packages, #versions, etc...
Sounds logic...just curious...why it is needed a "model" for Metacello Browser? cannot MB use the "Metacello model" directly ? I ask just by ignorance ehh.
That sounds good.
yes, that's why I aksed at the beginning :)
-- Mariano http://marianopeck.wordpress.com |
|
|
Mariano,
Haha, despite what you might think, I agree that once the "XML files" have been loaded into an image, that you've got a bunch of classes and you should be able to play with them, but the models have been evolving over time. It started with the core spec classes (the MetacelloSpec class hierarchy) that were designed to support conditional loading and distributed project references. Each version is composed from an OrderedCollection of the other specs ... the familiar #import statements concatenate the individual collections to compose the final version spec. The spec classes primary purpose it to manage package loading and really haven't changed an awful lot for the last couple of years. When Doru got involved, we (mostly Doru:) created the ConfigurationOf classes and the now familiar input DSL otherwise known as XML files. At this point in time it is fair to say that the "convention model" was created, however, the "convention model" did not have much in common with the underlying implementation in the MetacelloSpec hierarchy. Historically it has been fairly difficult to write scripts against Metacello for this very reason...One had to (somehow) know the mapping between the convention model and the spec model... Last fall I started work on the MetacelloToolBox with the plan to make Metacello more scriptable by providing a common API that could be used by tools and scripts ... I did end up with a scripting API, but the truth is there was still no implementation of the "convention model". Then Alexandre started writing MetacelloBrowser and since he was _trying_ to model the "convention model" very early on he created the MBInfo hierarchy... About the time that I added support for OmniBrowser to the MetacelloBrowser which involved consolidating all of the "business logic" in the MBInfo hierarchy, I began to recognize that the MBInfo classes _were_ modeling the "convention model" but I admit that I was still thinking along the lines of tools ... Now when you asked your question, the final (hah!) piece fell into place and I realized that we could use the MBInfo class hierarchy as the basis for the "convention model". Soooo, I don't think that the MBInfo hierarchy has quite the right structure for the final "convention model" - there are several classes and concepts that are only there in support of the tools. but I would appreciate it if you would take a look at the MBInfo hierarchy and see if it provides you with the things you need and identify the things that are missing, we can work on creating a better model... To give you a cooks tour of the structure, you start with MBConfigurationRoot. It has a list of MBConfigurationInfos that represent the Metacello configurations loaded into the image. Instances of MBConfigurationRoot are hooked into the system via announcements to ensure that the MBConfigurationRoot instance stays in synch with the image. Each MBConfigurationInfo manages a list of packages, projects, groups (based on the currentVersion for the project) and a list of (literal) versions and baselines. Each MBPackageInfo, MBProjectInfo and MBGroupInfo wraps the corresponding Metacello spec and maintains it's state relative to the image (workingCopy or currentVersion). Each MBBaselineInfo and MBVersionInfo wraps a Metacello version which (also) includes the list of packages, projects and groups associated with the version ... In this model I think that MBConfigurationInfo is a bit overloaded, directly managing both the versions/baselines as well as the packages/projects/groups for the currentVersion when it should manage just the versions/baselines and currentVersion. Anyway, I will be interested to hear what you think... Dale On Apr 10, 2011, at 5:58 AM, Mariano Martinez Peck wrote:
|
«
Return to Metacello
|
1 view|%1 views
| Free forum by Nabble | Edit this page |