Planning a .NET version

[benedfit]

I'm going to try and create a .NET version of pattern lab. Any guidance on what PHP functionality I'd be replacing would be appreciated to complement my own digging into the source. Plus any thoughts on the best way we could extract the static, language independent parts from PHP/.NET?

Cheers

[dmolsen]

This isn't exhaustive and I apologize that I don't have good docs already in the wiki. The master branch is the most stable branch to review. Dev is currently in quite a bit of flux and I'm not sure when it'll be resolved.

Features

To get the core working the easiest thing to do is just run through the functions referenced in generate() in builder/lib/generator.lib.php. That's essentially all of the basic functionality. e.g. that's how to generate pattern lab. I'd like to think I've done a decent job of commenting throughout. I did try to make it readable. The vast majority of the functionality lives in builder/lib/builder.lib.php. It sort of breaks down this way...

When constructing the Generatr class:

1. parse the config
2. figure out all of the pattern types and paths
3. get all the nav items

The nav item data is probably the most annoying. I don't have time right now to get examples of the structure of the data but maybe you can tease it out. That's just how a lot of the nav and history works.

When going through the generate() function:

1. gather data to be used in patterns
2. generate the patterns
3. generate the main index, styleguide, and view all pages

The "update change time" function is for the web socket stuff. You can skip that.

Static Assets

Basically anything under source/, public/, and config/ should be moveable. You can safely ignore listeners/, public/listeners/, and scripts/. Listeners is a feature that's not expected to be ported to other languages as I did that outside the scope of what Brad wanted. That's related to the web socket stuff for page reload and page follow. Scripts is just for Mac OS X users.

I'm open to changing the format of the config. That's just an easy format to use with PHP.

@bmuenzenmeyer might be able to chime in as well since he's had to poke through my code for a node.js version.

Brad and I appreciate interest in the ports so when we can help we'll try to. Thanks.

PS - your phases idea is currently working in dev branch. We've titled it "MQs" to fit in properly.

[bmuenzenmeyer]

Hi all,

It is exciting to see even more interest in patternlab - I'd be happy to provide some general insights into my porting process.

1. I found it incredibly useful to have a working version of PL-PHP alongside of my nodejs version. It's a great way to compare functionality.
2. Conversely, it was also helpful to depart from the structure of the PL-PHP when needed. I discovered after a bit that utilizing grunt was a great way to make use of already robust i/o, file watching, preprocessing, and logging. I chose to recurse through the patterns, but I think PL-PHP is using some globbing too.
3. The closeness between nodejs and mustache template/json, not to mention the finished product, made me feel very nimble. I wrote out a patternlab.json file for debugging purposes that essentially exposes the entire data model being constructed as patterns, menu items, partials, etc are built.
4. I am trying to use github flow to push small changes into the master branch. Getting up a minimal viable product first proved useful. My priorities have been the following:

   Compiled patterns individually Get the style guide working, which lists all patterns Get nested patterns and patterns with special data working Get patternlab site working

5. This priority was not without bumps in the road, however. I see some inefficiencies in doing this piece-mail, as a lot of patternlab.json data structures are very similar, but necessary downstream for various data models to be passed into templates. I suggest, if you loop through the pattern files at some point, is to build some objects that capture metadata about each. ie. Name, display name, relative path, absolute path, group name (atom, molecule, organism), template file, data file. etc.

If you have questions, you can let me know here, on twitter @bmuenzenmeyer or on the patternlab-node port.

[dmolsen]

I think point 2 is spot on. What makes sense for the language of the port is what a developer should build. The output is what's important and not necessarily how a port gets there. Point 5 is also an issue. Some of the data constructs obviously started separately and now, as I implement new features, they're getting closer to one structure. That's a part that needs to be refactored though probably not for a bit yet. Still trying to get the new features out. Hoping to get time here at BD Conf to make that happen :)

[bmuenzenmeyer]

Yeah I see opportunity to refactor too - but not until I can more like for like with PL-PHP. Had some trouble with View All, will take a step back and rethink my approach.

[benedfit]

Thanks for the input guys. Kicking off https://github.com/benedfit/patternlab-dotnet today

[benedfit]

Quick questions guys: Do you feel that ports need to stay true to the origins of being a static site generator?

[dmolsen]

You'd have to offer big caveats in your project if you didn't pursue the static site generator feature. A big goal of the project is to avoid install requirements. We consider Apache or any web server to be a requirement and work hard to avoid it. The builder language should be about it if at all possible.

We get two benefits from this. Really low overhead when trying out Pattern Lab and, more importantly, because a server isn't a requirement it means the project can be moved anywhere for review by a client. The iteration model with a client is really important and, again, we don't want to put a requirement on that. Conceivably, PL could be used on Dropbox.

At the end of the day, build the tool the way it makes sense for you. Just make sure you note where something may differ greatly from the reference edition.

[benedfit]

Thanks for the insight. I had planned to create MVC partial views for each pattern in order to reduce rewrite between prototype and 'production' code. But given the philosophy of PL, the requirement on .NET at runtime would be at odds with this. Gonna think about alternative approaches

[dmolsen]

closing this up. note that i opened issue #25 to deal with point 5 that @bmuenzenmeyer brought up.