Sean,
Sorry for the delay in getting to this question ...
First off, did you already figure things out?
If not, it's not clear to me what the difference is other than in the End-User Use Case, the end-user would load ResourcesLive directly:
Metacello new baseline: 'ResourcesLive' repository: 'github://XXX/ResourcesLive:master/repository' load: 'Default'.
and the Library use would be accomplished by encoding the Metacello doit in a BaselineOMyCoolProject project reference:
... spec baseline: 'ResourcesLive' with: [ spec loads: 'Default'; repository: 'github://XXX/ResourcesLive:master/repository' ]. ...
In the Library use case you may publish a different group that
would be used for library references, but that would only be
necessary if the Library use case required a different set of
packages ... If so you might publish a 'Library' group that
collected those libraries together ...
Dale
--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to metacello+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/metacello/dc9821ce-0434-4edc-bcc1-c4705517bfd8%40googlegroups.com.
Sorry for the delay in getting to this question ...
First off, did you already figure things out?
If not, it's not clear to me what the difference is other than...
I'm sorry when I'm being so dense, but I misunderstood the first
time, so I want to make sure I know what you're talking about this
time ...
AFAICT, we've got ResourcesLive and MyCoolProject dependency on
ResourcesLive .... so where does the "MetaC post-load doit" fit in
... Is this something associated with the ResourcesLive project or
the MyCoolProject or is MetaC yet another entity? Is "MetaC
post-load doit" going to be in a BaselineOf and if so where is it
sitting?
If I were to guess, this seems like a case where a Library group (and associated separately loaded package with Library post-load doit) and a separate top-level group (and associated separately loaded package with a Top-level post-load doit) would be called for?
What does you MetaC post-load doit need to do differently?
Dale
--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to metacello+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/metacello/178aead1-e7ca-4fcb-b340-056119099e98%40googlegroups.com.
AFAICT, we've got ResourcesLive and MyCoolProject dependency on ResourcesLive ....
so where does the "MetaC post-load doit" fit in ... Is this something associated with the ResourcesLive project or the MyCoolProject or is MetaC yet another entity? Is "MetaC post-load doit" going to be in a BaselineOf and if so where is it sitting?
If I were to guess, this seems like a case where a Library group (and associated separately loaded package with Library post-load doit) and a separate top-level group (and associated separately loaded package with a Top-level post-load doit) would be called for?
What does you MetaC post-load doit need to do differently?
What does you MetaC post-load doit need to do differently?
I guess I was looking for something that would happen automatically behind the scenes without the user (whether via library or end-user) having to worry about it, so they could use one script and get the right result.
But that "one script" will have an indication of whether or not it is using "a library" or "the app", so it is a matter of the end user choosing between the two (or more) ways of "using the thing they want to use" ... so I am not sure where the "automatic" comes into play ... if a post load doit for the "library" package and a different post load doit for the "application" package fills the bill then there is your answer ... or am I missing something else?
I _am_ interested in a specific answer to the "What does you
MetaC post-load doit need to do differently?", because I am
creating Rowan as we speak ...
Rowan has a "component" which is the loadable entity ... In Metacello "everything" was a loadable entity: package, group, and project ...
A "component" is a declared _and_ maintained chunk of
functionality, so in Rowan there could be an 'Application'
component and a 'Library' component and the end user would choose
to load one or the other depending upon what behavior/API they are
looking for ... components will have post load doits (in the next
week or so?:) ...
So I am interested in what other attributes and behind the scenes automation you are expecting (in more concrete terms) so I can try to include support for these in Rowan components.
So being a little more specific would help me understand what it is you think you are missing in Metacello ...
Dale
Dale Henrichs-3 wrote
But that "one script" will have an indication of whether or not it is
using "a library" or "the app"
Dale Henrichs-3 wrote
I _am_ interested in a specific answer to the "What does you MetaC
post-load doit need to do differently?"
Dale Henrichs-3 wrote
But that "one script" will have an indication of whether or not it is
using "a library" or "the app"
Maybe I'm oversimplifying, but I envisioned these two use cases:
"End-User Mode" which would load via MetaC scripting APIMetacello newbaseline: 'ResourcesLive';repository: 'github://seandenigris/ResourcesLive';load.
"Library Mode" which would load via another baselinespec baseline: 'ResourcesLive' with: [spec repository: 'github://seandenigris/ResourcesLive' ]
I wanted to avoid having to specify additional information like a group.Maybe I'm being too picky? I guess it wouldn't be much more code to have:spec baseline: 'ResourcesLive' with: [spec repository: 'github://seandenigris/ResourcesLive';loads: 'Library-Mode' ]
I don't know about picky, but there needs to be something that
differentiates between "Library Mode" and "End-User Mode" so that
the correct initialization procedure is run ... some one has to
tell Metacello what doit to run and when ... and for Metacello
that's a post load doit associated with a package ...
Dale Henrichs-3 wrote
I _am_ interested in a specific answer to the "What does you MetaC
post-load doit need to do differently?"
In "End-User" mode, ResourcesLive would be responsible for it's ownpersistence, so it would enable that (currently in a class-side initialize)[1]. In case it's relevant, the real work in that method happens inSimplePersistence here [2]
Thanks for the info ... I think I've got a clearer picture about what you are trying to do and I might have this covered for Rowan ... in Rowan there is the notion of a component. The component is the THE loadable entity in Rowan (as opposed to package, group, project in Metacello) and a component is a list of (conditional) package names and/or component names ... and a component has (will have:) pre and post load doits, so in your case there would be an "End-User" component and a "Library" component and each would have a unique post load doit ... There's only so much you can squeeze into a Metacello baseline spec method and only so much meta data (basically none:) that you can add to a package ... so it would take a substantial rewrite of Metacello to add the notion of "component" to Metacello...
Thanks for the information,
Dale
--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to metacello+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/metacello/14384984-99b6-49c0-9925-3f751e71da2a%40googlegroups.com.