New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create configurations that can be used with YUI.applyConfig function for external modules #83

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
3 participants
@bretkikehara

Motivation

Previously, any external module configuration that are external from the YUI modules or gallery needed to be hand crafted. Yogi will help in creating the directory structure for a module, but will not help with configuring external modules for loading.

This code hooks into the current process used to configure the YUI module and redirects the output for external module loading. Following the Shifter's pattern, @modules@ will be replaced by the module data. Since the module data is replacing a pattern, the generated output cannot be linted.

How to Use:

An example of a basic configuration file.

YUI.applyConfig({
  groups: {
    extGroupName: {
      modules: @MODULES@
    }
  }
});

Expected output:

YUI.applyConfig({
  groups: {
    extGroupName: {
      modules: {
        "module1" : {
          "requires" : ["node"]
        }
      }
  }
});
@caridy

This comment has been minimized.

Show comment
Hide comment
@caridy

caridy Jul 12, 2013

Member

IMO this should be a yogi extension, similar to yogi-app package for two reasons:

  • yui core or gallery modules will not need this feature
  • shifter/yogi can produce meta modules, which is a more desirable way to define metadata that can be piped into YUI without the manually applyConfig call.

which makes me think this is more app specific feature, feel free to fork yogi-app.

Member

caridy commented Jul 12, 2013

IMO this should be a yogi extension, similar to yogi-app package for two reasons:

  • yui core or gallery modules will not need this feature
  • shifter/yogi can produce meta modules, which is a more desirable way to define metadata that can be piped into YUI without the manually applyConfig call.

which makes me think this is more app specific feature, feel free to fork yogi-app.

@evocateur

This comment has been minimized.

Show comment
Hide comment
@evocateur

evocateur Jul 12, 2013

@caridy I didn't know about yogi-app, and a big honking "experimental" in the header doesn't inspire confidence.

yui core or gallery modules will not need this feature

I don't see how this precludes an option (off by default) being added, except as it pertains to increased complexity. I can think of many, many times in my own YUI-based projects that I would like something like this.

shifter/yogi can produce meta modules ...

Yes, but with the unceremonious death of grifter, we no longer have even the faint hope of meta-module config that incorporates our custom modules without burdening us with the entire library.

Even in a world with fancy grifter-like config generation, something like this is still desirable in cases when you want to customize YUI's config and separate your app's (e.g., different comboBase configs and the like). I'm not sure YUI.applyConfig() is the best way to go about this, but the need for external group generation remains.

@caridy I didn't know about yogi-app, and a big honking "experimental" in the header doesn't inspire confidence.

yui core or gallery modules will not need this feature

I don't see how this precludes an option (off by default) being added, except as it pertains to increased complexity. I can think of many, many times in my own YUI-based projects that I would like something like this.

shifter/yogi can produce meta modules ...

Yes, but with the unceremonious death of grifter, we no longer have even the faint hope of meta-module config that incorporates our custom modules without burdening us with the entire library.

Even in a world with fancy grifter-like config generation, something like this is still desirable in cases when you want to customize YUI's config and separate your app's (e.g., different comboBase configs and the like). I'm not sure YUI.applyConfig() is the best way to go about this, but the need for external group generation remains.

@bretkikehara

This comment has been minimized.

Show comment
Hide comment
@bretkikehara

bretkikehara Jul 12, 2013

@evocateur Basically, the meta data will replace the @modules@ pattern, so the config.js file is not limited to using YUI.applyConfig(). In my case, that came out to be the best option.

@evocateur Basically, the meta data will replace the @modules@ pattern, so the config.js file is not limited to using YUI.applyConfig(). In my case, that came out to be the best option.

@caridy

This comment has been minimized.

Show comment
Hide comment
@caridy

caridy Jul 15, 2013

Member

@evocateur

"except as it pertains to increased complexity"

that's a strong enough reason in my opinion. if we add all features that are "nice to have" into shifter/yogi, we will end up with a giant piece of junk. that's why @davglass added a provision for extensions that is really easy to use, where you inherit all the features provided by the original tool, but you can add few more bits to do what you want.

"the need for external group generation remains"

sure! but the reality is that each app is different, some people feel confortable using build.json and the raw code that needs to be compiled, others prefer to just drop the YUI.add() in their app folder, so people like to have all yui modules grouped in the same folder, some just want to organize it by logical groups, etc. What this means is that we should provide the right api and the right guidelines for people to create the tools they need to fulfill their use-case, rather than trying to push everyone to follow certain pattern.

about yogi-app, and a big honking "experimental"

yeah, we started with that, but we decided to go in a different direction. basically, having a tool that will rely on a configuration to describe something as complex as an app, it is not a good idea. for a library with a very strict definition and guidelines for contributors is fine but not for a complex app. so, we decided to use a program to describe how the app should be build, and that's the principle we are using in modown. I did a quick writeup for you guys to try it:

https://gist.github.com/caridy/6000858

eventually I will update yogi-app, I just don't know when. :)

Member

caridy commented Jul 15, 2013

@evocateur

"except as it pertains to increased complexity"

that's a strong enough reason in my opinion. if we add all features that are "nice to have" into shifter/yogi, we will end up with a giant piece of junk. that's why @davglass added a provision for extensions that is really easy to use, where you inherit all the features provided by the original tool, but you can add few more bits to do what you want.

"the need for external group generation remains"

sure! but the reality is that each app is different, some people feel confortable using build.json and the raw code that needs to be compiled, others prefer to just drop the YUI.add() in their app folder, so people like to have all yui modules grouped in the same folder, some just want to organize it by logical groups, etc. What this means is that we should provide the right api and the right guidelines for people to create the tools they need to fulfill their use-case, rather than trying to push everyone to follow certain pattern.

about yogi-app, and a big honking "experimental"

yeah, we started with that, but we decided to go in a different direction. basically, having a tool that will rely on a configuration to describe something as complex as an app, it is not a good idea. for a library with a very strict definition and guidelines for contributors is fine but not for a complex app. so, we decided to use a program to describe how the app should be build, and that's the principle we are using in modown. I did a quick writeup for you guys to try it:

https://gist.github.com/caridy/6000858

eventually I will update yogi-app, I just don't know when. :)

@evocateur

This comment has been minimized.

Show comment
Hide comment
@evocateur

evocateur Jul 15, 2013

@caridy Thanks for the well-reasoned replies, and the gist. :)

After reading your reply, this particular PR does seem rather like an extension utility, not core.

@caridy Thanks for the well-reasoned replies, and the gist. :)

After reading your reply, this particular PR does seem rather like an extension utility, not core.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment