3 ms·

These are great points, and I certainly agree that some convention is required in template development to ensure "less brittleness". I think it's simple enough

by dools 15y ago

These are great points, and I certainly agree that some convention is required in template development to ensure "less brittleness". I think it's simple enough to do this with ids and classes, though, and even when it does break, the time it takes to fix it is going to have a pretty trivial impact on your overall project because the problem is solvable, quite simply and without much hunting around, by one person without the need to communicate with anyone else on the team. Regarding the logic issue, I don't think you'd realistically end up with an intractable number of logic variations. If you have extra links that are there when the moderator is logged in, they should be there in any template with that structural element in it and then removed if the person logged in isn't a moderator. Granted, though, I have to put my money where my mouth is and port one of my existing applications over to using this methodology (which is, in fact, what I plan to do so the proof the pudding will be in the eating). Regarding the issue of "viewing the template without a server" - in the case of Fragmentify, all the frontend dev needs is the standard apache/php that ships with OSX. This is considerably less complex than having an entire framework/application environment installed and kept current. That being said, however, the way in which templates arrive at the "animator" is not the animator's problem. Dreamweaver lets you edit common assets and then exports head-to-foot complete HTML files in a ZIP, so just use that. So long as the "animotor" has complete HTML files to work with, that's all that matters.

judofyr 15y ago
> I think it's simple enough to do this with ids and classes, though, and even when it does break, the time it takes to fix it is going to have a pretty trivial impact on your overall project because the problem is solvable. The real issue is that now the designer needs to mentally figure out "is this a safe refactoring" for every change. Because he doesn't have the real application running there, he can't verify if it works or not. I fear that this might lead to "leave the markup alone; change CSS only"-mentality from the designers because they don't want to introduce the animators for a simple design change. (You might say that changing only the CSS was the "right" solution anyway, but sometimes things becomes more much simpler when you can e.g. just wrap something in a div). > If you have extra links that are there when the moderator is logged in, they should be there in any template with that structural element in it and then removed if the person logged in isn't a moderator. Aha, but how can the designer see how it looks like for regular users? He probably wants to make sure that it looks good without the link too (maybe it's more like a button which floats). It seems like a sub-optimal workflow to manually remove the link (or display:none it) every time he works on the regular user page. (He must also remember to put it back in.) > This is considerably less complex than having an entire framework/application environment installed and kept current. Fair enough. > … Dreamweaver … If an editor can make it easier to work with the templates, that's good. Just don't make it impossible to work with the files unless you use some proprietary editor…
hetman 15y ago
You're assuming the breakage will be something obvious and clearly visible. No doubt many of them will be. However, I would foresee plenty of breakages in obscure or not immediately apparent places which may not be noticed for some time. For example they may be minor (yet still very annoying for users stumbling on them) or apparent in only certain circumstances.
- dools 15y ago
  Well - that's kinda what testing is for. It would remain to be seen whether or not this proves to really be the intractable problem you're imagining it to be - let's not forget that any other method will also produce bugs. The question is whether they're produced at the same rate or not. I have no evidence to really say whether or not what you're imagining would be prohibitive to using this method but my (strong) opinion is that it wouldn't be (time will tell as I put this into practice though, and I'll be following up with more posts about it).

by dools 15y ago

judofyr 15y ago

> I think it's simple enough to do this with ids and classes, though, and even when it does break, the time it takes to fix it is going to have a pretty trivial impact on your overall project because the problem is solvable. The real issue is that now the designer needs to mentally figure out "is this a safe refactoring" for every change. Because he doesn't have the real application running there, he can't verify if it works or not. I fear that this might lead to "leave the markup alone; change CSS only"-mentality from the designers because they don't want to introduce the animators for a simple design change. (You might say that changing only the CSS was the "right" solution anyway, but sometimes things becomes more much simpler when you can e.g. just wrap something in a div). > If you have extra links that are there when the moderator is logged in, they should be there in any template with that structural element in it and then removed if the person logged in isn't a moderator. Aha, but how can the designer see how it looks like for regular users? He probably wants to make sure that it looks good without the link too (maybe it's more like a button which floats). It seems like a sub-optimal workflow to manually remove the link (or display:none it) every time he works on the regular user page. (He must also remember to put it back in.) > This is considerably less complex than having an entire framework/application environment installed and kept current. Fair enough. > … Dreamweaver … If an editor can make it easier to work with the templates, that's good. Just don't make it impossible to work with the files unless you use some proprietary editor…

hetman 15y ago

You're assuming the breakage will be something obvious and clearly visible. No doubt many of them will be. However, I would foresee plenty of breakages in obscure or not immediately apparent places which may not be noticed for some time. For example they may be minor (yet still very annoying for users stumbling on them) or apparent in only certain circumstances.

dools 15y ago
Well - that's kinda what testing is for. It would remain to be seen whether or not this proves to really be the intractable problem you're imagining it to be - let's not forget that any other method will also produce bugs. The question is whether they're produced at the same rate or not. I have no evidence to really say whether or not what you're imagining would be prohibitive to using this method but my (strong) opinion is that it wouldn't be (time will tell as I put this into practice though, and I'll be following up with more posts about it).