Should public/listeners and public/patterns be moved for better portability?

[benedfit]

Putting the case out that for better portability, that the listeners and patterns folders should be moved into the styleguide folder as they aren't likely to be used in a final production environment the same way as css/fonts/images/js would be.

Additionally feel that there could be a copy of index.html under styleguide folder for future portability

Thoughts?

[dmolsen]

I guess I'm not quite getting the use case here. Would you mind clarifying?

I tend to think of public/ as for client review and, possibly, a final style guide. But the stuff in there isn't really for production use in the sense that "This is my website." I could see moving public/listeners/ just because it is more style guide-ish. Patterns though... not quite seeing it yet.

Thanks.

[benedfit]

I am also thinking that Pattern Lab would serve as the final styleguide. But given the fact that the CSS, js, etc created in the folders under public are not style guide specific as such the public folder could in theory form the foundation of a production code base.

The thinking behind moving patterns was that in such an environment as described above, the HTML generated by Pattern Lab could be rewritten into a different format during implementation and having patterns under styleguide would lend it to being a snapshot of pre-integrated code.

I hope that makes things a bit clearer?

[dmolsen]

Ok, I see where you're going with this. I think this is a longer-term discussion with @bradfrost. I don't think a reorganization is really needed with the use case. We could just as easily have a "generate final" step that blows out public/ and dumps in css, js, images, and the Page-based templates. Or it could build to an export/ directory as well. The latter might be better as it might be clearer what someone is trying to do or going to get.

Thanks for the idea :)

[bradfrost]

This is an interesting conversation to have. As it is right now, Pattern
Lab isn't meant to be the end-all be-all codebase, but at the same time, if
done properly, there's no reason why it wouldn't make sense to use this as
your production code base. I don't have any further thoughts right now, but
it's definitely something we should continue to talk about.

---

Brad Frost
http://bradfrostweb.com
http://twitter.com/brad_frost

On Sat, Nov 9, 2013 at 11:56 AM, Dave Olsen notifications@github.comwrote:

Ok, I see where you're going with this. I think this is a longer-term
discussion with @bradfrost https://github.com/bradfrost. I don't think
a reorganization is really needed with the use case. We could just as
easily have a "generate final" step that blows out public/ and dumps in
css, js, images, and the Page-based templates. Or it could build to an
export/ directory as well. The latter might be better as it might be
clearer what someone is trying to do or going to get.

Thanks for the idea :)

—

Reply to this email directly or view it on GitHubhttps://github.com//issues/40#issuecomment-28131352
.

[benedfit]

I am hoping that the .NET version I'm working on will become the foundation for all the projects I work on moving forward. So kicking off this conversation was purely for selfish reasons :)

However the MVC structure I'm using does lend itself to Pattern Lab being a sub project within a larger code base. It's also very likely that this version of Pattern Lab may stray from the static site generation ethos you currently have, but again this is more for my personal gain

[GriffinArtworks]

HI I am in the middle of a large project, where we will most likely end up bootlegging some sort of export, anyway. So I would second an "export" feature as a great idea. It makes for a very nice project workflow.

[dmolsen]

@GriffinArtworks -

Noted. Thanks :)

[dmolsen]

synclisteners.js has been moved from public/listeners to public/styleguide/js/. Since I don't plan to move public/patterns/ and the export/ use case has arisen I've created a new issue, #67. Closing this one.