Hi Justin -
I don't think I agree with this suggestion, since it seems to me to be based on an over-optimistic view of
the economies. We will be adopting one of these solutions as a crucial part of our infrastructure, that is,
as a platform - and therefore investigating their configurability, for a which a good proxy is the ease of
writing a plugin, is essentially the #1 criterion for adoption. Therefore the costs say, of writing two or
more plugins, or at the very least, assessing the difficulty of writing a plugin, simply can't be avoided.
These are costs that we will have to pay as a community sooner or later, and we may as well just try to
minimise them. We needn't go through the entirety of the exercise of writing a plugin during this initial
round, but my suggestion is that it is an essential part of the earliest part of the exercise. We should not
be committing ourselves to a "waterfall" model of evaluating the platforms.
Also, to try to reduce the risks from the "prototype goes into production" route which history suggests can
never be completely blocked, I'd like to suggest that at the very least any "plugin-free" initial evaluation
is done with handlebars rather than jade, since its templates at least resemble some kind of markup. All of
our candidates support this option either out of the box or with an already existing plugin.
Cheers,
Antranig
On 28/01/2014 14:20, Justin Obara wrote:
Hi Colin,
Just to clarify things. I'm not suggesting that we actually use Jade here on
out, just that in terms of evaluating the two static site generators, it has
less of an impact. That being said, evaluating the ease of writing plugins is
useful, but since they both support template plugins, and that's likely not
something we will be doing often, it seemed reasonable to drop this requirement
for the evaluation round.
What I would suggest instead is that we aim to collect information on the ease
of use and viability of the static site generators and present this along with
a recommendation on which one to go with, for the Feb 19th community meeting.
This recommendation will come with the caveat that we will need to attempt to
write a Weld plugin for it. At which point we can decide as a community if we
want to go with the recommended static site generator. In this way, we won't
have to spend the time to write two plugins.
I agree that we need to keep the big picture in mind and be forward looking.
Also, I'd really like to avoid having to rewrite mounds of templates if we
change the templating engine in the future. Using plain markup seems the best
way forward for this. I hope my proposal can achieve this, as well as minimize
the resource cost of evaluation.
Let me know what you think.
Thanks
Justin
On Jan 28, 2014, at 2:25 PM, Colin Clark <[email protected]> wrote:
On Jan 28, 2014, at 11:19 AM, Justin Obara <[email protected]> wrote:
"Why Weld?" is a good question. The simple answer is that it doesn't require
any special syntax mixed in with the markup. This allows for clean templates that are
valid markup. Which fits with our philosophies in Infusion and will be an easier
transition if we switch to an internally made rendering system some time in the future.
That being said, since none of them support it directly and we can write
plugins for all of them, maybe we can defer this to later and just start wtih
Jade for our evaluation.
As a community, we have been dedicated to exploring alternatives to the “all
mixed together” model of templating that is the prevailing style inherited from
PHP. We should continue to pursue this value of unobtrusiveness and separation
of the architectural layers with the tools we use for our own work.
Writing a plugin for Weld templates will also be an excellent opportunity to
verify the flexibility of the options we are considering. Keep in mind that
within the next year or so, we will have our new Renderer available, and will
undoubtedly want to integrate it into whatever solution we end up choosing.
Let’s not loose sight of the big picture while choosing shorter-term
technologies to use in our community.
I hope this helps clarify,
Colin
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
