7

Preface

I'm designing a templating language (please skip the don't/why?? speech). One of the major goals of this language is to be extensible. There are 2 main elements in my language. "Tags" and "Directives". Tags, for the most part, map 1-to-1 to HTML tags, with the exception of a few of them which do a bit more. "Directives" are things like conditionals and for/while loops.

"Tags" are simple, because they all follow the same structure: tag_name(arg1=val1, arg2=val2) { content }.

Directives are more complicated because they look like this: directive(anything-can-go-here) { content }.

Question

I'm trying to decide how to let users (other devs using the templating language) write their own directive -- i.e., define the "anything can go here" part.

I'm using Irony to parse my language. Should I give them the same level of access, and define their own BnfExpression (requiring them to learn a bit of Irony/EBNF), or should I just toss them a string (the stuff between ( and )) and let them parse it however they want?

My Concerns

The former is perhaps more powerful and easier to work with (once you know it), but it would also potentially give them too much power (they wouldn't have to stop at the next ) -- well, unless I stripped out the inner string first and then basically let them define a sub-grammar to parse only that).

Not sure how to approach this.

More About Tags

For reference, users can define "tags" like this:

class ANode : HtmlNode
{
    public ANode(AttrDict attrs, params TagNode[] children)
        : base("a", attrs, children) { }
}

Would be the most basic example, which just extends the HtmlNode I've already defined. A more complicated one might define some default attributes or do something fancy with the child elements, or generate multiple html tags.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
mpen
  • 1,889
  • 19
  • 29
  • 1
    How do extract the inner string in the first place? What if it too contains a parentheses? – alternative Apr 24 '11 at 00:21
  • It would stop at the first parenthesis not contained in quotes. Which is *probably* the behaviour they'd want, but I suppose not necessarily. – mpen Apr 24 '11 at 01:32
  • Should you let your users write BNF grammar statements? Only if your users don't go on shooting sprees over the stress of Shift/Reduce or Reduce/Reduce conflicts. – riwalk May 12 '11 at 04:09
  • @Stargazer712: I'll take that as a "no". – mpen May 12 '11 at 06:32
  • @Ralph, your users would go on shooting sprees over errors? I'm not sure that ... wait ... who are you writing this for again??? :) – riwalk May 12 '11 at 17:53
  • @Stargazer712: Web developers. So.. they might not necessarily be expert programmers, but they should have a least a bit of programming experience. Designers might want to create some new tags too... I dunno if companies actually have someone dedicated to writing just the templates, but if they do, they could still get their programmer ally to create the new tag for them. I dunno, that's who I envision using it, but it'll probably just end up being me and me alone :) – mpen May 13 '11 at 15:27

1 Answers1

2

There are many factors that should go into this decision. Here are some things to consider:

Requirements: Are there use cases that require this capability be present, or would be substantially easier to deliver if you provide this capability?

Schedule: Adding this feature may delay the completion of your project. How much money do you (or your company) lose if the product launch is delayed?

Cost / Benefit Tradeoff: It will cost you something to provide this capability. You have to write code, you have to write test cases, your testers have to perform these tests, you need to write end-user documentation. Once the product is deployed, this capability will need to be supported. You can estimate these costs, and balance them with any benefits that you will get from providing this capability. Will you be able to sell your product at a higher price, or will you be able to sell more of them?

Jay Elston
  • 2,680
  • 22
  • 30
  • Well I'm basically deciding between two choices. Going the EBNF route would probably be easier to implement. Time/money are not concerns; I'm still following an idealistic approach :) – mpen May 14 '11 at 01:01