printable, user (non-programmer) templating / reporting mechanism (e.g. for awards script) [sf#214]

[jpschewe]

Need to research/find a good mechanism to take a source document, perhaps a PDF (or PPT/Word) and replace some values with results of a report from the database.

Just to be clear, this needs to be something that a non-programmer can edit, in theory, up until the day of the tournament.

First application of this is to generate the awards script.

[jpschewe]

• owner changed from jpschewe to jjkoletar
• status changed from new to assigned

Depending on how we end up implementing this, it might be possible to make premade reports like Playoff Winners, Ranking Reports, etc, just premade templates that could be modified by the user.

I feel like this isn't fully "critical", as the only other tournament we have is the non-advancing, so if nobody minds, I'd like to be the one to look into this.

[jpschewe]

Replying to jjkoletar:

Depending on how we end up implementing this, it might be possible to make premade reports like Playoff Winners, Ranking Reports, etc, just premade templates that could be modified by the user.

Agreed - there is NO reason why the current reports shouldn't be done with the same mechanism.

I feel like this isn't fully "critical", as the only other tournament we have is the non-advancing, so if nobody minds, I'd like to be the one to look into this.

No, not critical. Have at it. However, anything we can get before next season's first regional tournaments would be great.

[jpschewe]

• cc jpschewe added
• priority changed from critical to minor

On 2/3/13 8:00 AM, Jon Schewe wrote:

Where do you want this document presented? If it's on the screens, then we should probably set it up to be an HTML presentation. If if should be printed it should be PDF. Otherwise this is just a word template.

I think the best output format would be PDF, if only because then the reports have a better chance of looking nice. That is, unless there is some HTML[5] with CSS modules which make the development of templates easy (because you can also plug-in JavaScript?).

I don't see why we can't come up with a way to display, inline, PDF documents via the current server system. Even putting the PDF through a slide-show mechanism in the case of multiple pages.

Plus, since some of the reports are meant to be printed (e.g. the ranking report and the awards script), PDF would have a better chance of coming out like you want it to look.

As for Word (or PPT) - I know I put that in there, and two obvious benefts:

(1) most everybody would have it available. (2) they wouldn't have to be a programmer, perhaps.

The problem is, I don't know if that will work. Will we be able to interleave the "boilerplate" and the SQL calls in such a way to make it easy to modify, esp by a non-programmer.

Step one is NOT to dive into an implementation, but see what ideas others have tried/built.

[jpschewe]

Apache Velocity seems like it'd be very convenient for the replacement vars, but not for the rich text. Maybe bridge velocity and iText somehow?

[jpschewe]

Replying to jjkoletar:

Apache Velocity seems like it'd be very convenient for the replacement vars, but not for the rich text. Maybe bridge velocity and iText somehow?

yeah - that might work. I had forgotten about Velocity. Could also look at ztemplates, though it looks slightly stale, or spring framework. Either might be a good thing to look at. I found them look at this Power By Velocity

It occurs to me that if this works, and we can come up with a good method for generating PDFs that also does HTML (live via AJAX?), we could use it to redevelop/design the rest of the system too - the scoreboard and brackets...

[jpschewe]

Replying to eengstrom:

On 2/3/13 8:00 AM, Jon Schewe wrote:

Where do you want this document presented? If it's on the screens, then we should probably set it up to be an HTML presentation. If if should be printed it should be PDF. Otherwise this is just a word template.

I think the best output format would be PDF, if only because then the reports have a better chance of looking nice. That is, unless there is some HTML[5] with CSS modules which make the development of templates easy (because you can also plug-in JavaScript?). I don't see why we can't come up with a way to display, inline, PDF documents via the current server system. Even putting the PDF through a slide-show mechanism in the case of multiple pages.

I've resisted displaying PDFs on the screens as we don't have the PDF plug-ins installed on most of our systems and even then they don't always work. Personally I always uninstall/disable the plug-ins because I find the experience in an external viewer much better and less likely to crash.

Also I don't think you can automatically advance PDFs, so you need someone at the display computer advancing the slides like we did at State. If you did a nice job with HTML and made each slide be a separate page, then we could just advance them from anywhere and it'd display on anything. There's a template from Google that one could start with: http://code.google.com/p/html5slides/

Plus, since some of the reports are meant to be printed (e.g. the ranking report and the awards script), PDF would have a better chance of coming out like you want it to look.

Yes, for printing PDFs work much better as you can do clean page breaks.

As for Word (or PPT) - I know I put that in there, and two obvious benefts: (1) most everybody would have it available.

Except that none of the computers we use have it installed nor do we have licenses for it, even if we were running Windows.

(2) they wouldn't have to be a programmer, perhaps. The problem is, I don't know if that will work. Will we be able to interleave the "boilerplate" and the SQL calls in such a way to make it easy to modify, esp by a non- programmer.

So you're thinking that you want someone to be able to define the templates at the tournament? That sounds like you would need a programmer. I could see them being filled in by a non-programmer fairly easily with some forms.

[jpschewe]

Replying to eengstrom:

Replying to jjkoletar:

Apache Velocity seems like it'd be very convenient for the replacement vars, but not for the rich text. Maybe bridge velocity and iText somehow?

I've used velocity before. It's great for outputting simple formats; PDF is not likely to be one that will work well. If you can find an example that outputs PDF, then we've got something to work from. We'd essentially need to write iText from scratch. I see that one could output RTF, we might be able to build on that if RTF were acceptable, although I'm not sure how that would display in a web page.

yeah - that might work. I had forgotten about Velocity. Could also look at ztemplates,

ztemplates may help, although I think it's geared more towards templates for code than for graphical templates.

though it looks slightly stale, or spring framework.

I don't think spring is a templating framework. It's more for plugging different modules together with few dependencies.

Either might be a good thing to look at. I found them look at this Power By Velocity

Notice the formats that are outputs of these usages.

It occurs to me that if this works, and we can come up with a good method for generating PDFs that also does HTML (live via AJAX?), we could use it to redevelop/design the rest of the system too - the scoreboard and brackets...

Realize that what we do for display right now is already a template. I'm very hesitant to replace all of the displays we have with a generic template library mechanism when we have one that works right now.

[jpschewe]

Replying to jpschewe:

Replying to eengstrom:

I think the best output format would be PDF [...]

I've resisted displaying PDFs on the screens as we don't have the PDF plug- ins installed on most of our systems and even then they don't always work. Personally I always uninstall/disable the plug-ins because I find the experience in an external viewer much better and less likely to crash.

Good point.

Also I don't think you can automatically advance PDFs, so you need someone at the display computer advancing the slides like we did at State. If you did a nice job with HTML and made each slide be a separate page, then we could just advance them from anywhere and it'd display on anything. There's a template from Google that one could start with: http://code.google.com/p/html5slides/

Both good points. I'm convinced that an HTML approach will be better for anything that we display at a tournament. The only two things I can think of that we want to display now are:

1. callbacks for finalist judging (at state)
2. award nominations/winners ppt show - complete with pictures of the teams - Sara V. has put this together (and pushed the buttons) in past years. (only at state)

Perhaps I'm forgetting something, but if not, note that both of them are at state. Of the two, the first is the MOST important, assuming we can generate the schedule correctly. The latter is much more fiddly, and can be punted on until we have something that works for the former.

Plus, since some of the reports are meant to be printed (e.g. the ranking report and the awards script), PDF would have a better chance of coming out like you want it to look.

Yes, for printing PDFs work much better as you can do clean page breaks.

The first thing I really want is the awards scripts, and those never see the light of the projector - it's only for my consumption (or others giving awards).

As for Word (or PPT) - I know I put that in there, and two obvious benefts: (1) most everybody would have it available.

Except that none of the computers we use have it installed nor do we have licenses for it, even if we were running Windows.

Only need it on the server where the report is generated. Or, if client side, then only on the computer generating the report, which could be my mac.

(2) they wouldn't have to be a programmer, perhaps. The problem is, I don't know if that will work. Will we be able to interleave the "boilerplate" and the SQL calls in such a way to make it easy to modify, esp by a non- programmer.

So you're thinking that you want someone to be able to define the templates at the tournament?

Not at the tournemnt. Before the tournamnet(s). The regional awards script should be defined well before the tournaments and doesn't need to change.

That sounds like you would need a programmer. I could see them being filled in by a non-programmer fairly easily with some forms.

Forms? Web forms? That sounds like a lot of programmer work, and would have to chnage from year to year, likely.

Replying to jpschewe:

[... lots of talk about possible tools ...]

I have no stake in which templating mechanism. I only care that it's relatively easy to use, and perhaps even by a non-programmer.

The notional work flow I have in mind is that someone (Norm or I) write the awards script, using some pre-defined or parameterizable queries to fill in what gets pulled from the server/database. Things like, "top 'n' in category 'y'".

It occurs to me that if this works, and we can come up with a good method for generating PDFs that also does HTML (live via AJAX?), we could use it to redevelop/design the rest of the system too - the scoreboard and brackets...

Realize that what we do for display right now is already a template. I'm very hesitant to replace all of the displays we have with a generic template library mechanism when we have one that works right now.

How is it a template if someone like Norm can't get at it? When I use the word template, it's something that someone who doesn't know programming can write. Like a mail-merge template, with special markup to tell the system what to fill in "here" and "here" and "here...

What do you mean by template?

[jpschewe]

Replying to eengstrom:

Replying to jpschewe:

Replying to eengstrom:

I think the best output format would be PDF [...]

Also I don't think you can automatically advance PDFs, so you need someone at the display computer advancing the slides like we did at State. If you did a nice job with HTML and made each slide be a separate page, then we could just advance them from anywhere and it'd display on anything. There's a template from Google that one could start with: http://code.google.com/p/html5slides/

Both good points. I'm convinced that an HTML approach will be better for anything that we display at a tournament. The only two things I can think of that we want to display now are: 1. callbacks for finalist judging (at state)

2. award nominations/winners ppt show - complete with pictures of the teams - Sara V. has put this together (and pushed the buttons) in past years. (only at state) Perhaps I'm forgetting something, but if not, note that both of them are at state. Of the two, the first is the MOST important, assuming we can generate the schedule correctly. The latter is much more fiddly, and can be punted on until we have something that works for the former.

I think those are the main ones we've been worried about. If the schedule is generated properly I think we already have something to display, or will with some minor changes to the finalist scheduling code. The display during the awards is the big one.

Plus, since some of the reports are meant to be printed (e.g. the ranking report and the awards script), PDF would have a better chance of coming out like you want it to look.

Yes, for printing PDFs work much better as you can do clean page breaks.

The first thing I really want is the awards scripts, and those never see the light of the projector - it's only for my consumption (or others giving awards).

And we should be able to generate that PDF pretty easily given the basic layout of the awards script and then having your or Norm answer some questions on a web page that then generates the PDF, just like the finalist scheduling.

That sounds like you would need a programmer. I could see them being filled in by a non-programmer fairly easily with some forms.

Forms? Web forms? That sounds like a lot of programmer work, and would have to chnage from year to year, likely.

Forms that are already written and that you or Norm fill in.

Replying to jpschewe:

[... lots of talk about possible tools ...]

I have no stake in which templating mechanism. I only care that it's relatively easy to use, and perhaps even by a non-programmer. The notional work flow I have in mind is that someone (Norm or I) write the awards script, using some pre-defined or parameterizable queries to fill in what gets pulled from the server/database. Things like, "top 'n' in category 'y'".

It occurs to me that if this works, and we can come up with a good method for generating PDFs that also does HTML (live via AJAX?), we could use it to redevelop/design the rest of the system too - the scoreboard and brackets...

Realize that what we do for display right now is already a template. I'm very hesitant to replace all of the displays we have with a generic template library mechanism when we have one that works right now.

How is it a template if someone like Norm can't get at it? When I use the word template, it's something that someone who doesn't know programming can write. Like a mail-merge template, with special markup to tell the system what to fill in "here" and "here" and "here... What do you mean by template?

This is referring to Jeremy's idea of replacing the current brackets and scoreboard with a generic templating engine. What we have already is a template, we write some HTML code and then Java fills in the dynamic data and the combined result is then displayed on the screen.

So it looks like the outcome here these actions:

1. make sure we can generate HTML to display the finalist schedule
2. create the ability to generate an HTML display for during awards, this will involve uploading pictures and entering team number information or selecting from a list. This should be able to be controlled in a reasonable fashion, likely from another computer like we do for the brackets.
3. Create the ability to generate a PDF report for the awards script

[jpschewe]

Replying to jpschewe:

Replying to eengstrom:

The only two things I can think of that we want to display now [ that we don't already display ]are: 1. callbacks for finalist judging (at state) 2. award nominations/winners ppt show - complete with pictures of the teams - Sara V. has put this together (and pushed the buttons) in past years. (only at state)

I think those are the main ones we've been worried about. If the schedule is generated properly I think we already have something to display, or will with some minor changes to the finalist scheduling code. The display during the awards is the big one.

Have something, yes, but if you don't mind, it's really ugly. It needs a facelift, minimally.

The first thing I really want is the awards scripts, and those never see the light of the projector - it's only for my consumption (or others giving awards).

And we should be able to generate that PDF pretty easily given the basic layout of the awards script and then having your or Norm answer some questions on a web page that then generates the PDF, just like the finalist scheduling.

But what about the words around the awards script. It changes each year. it's long. I don't want to have to have your (or worse me) "program" it in. Take a look at it in the dropbox folder.

That sounds like you would need a programmer. I could see them being filled in by a non-programmer fairly easily with some forms.

Forms? Web forms? That sounds like a lot of programmer work, and would have to chnage from year to year, likely.

Forms that are already written and that you or Norm fill in.

Sounds inflexible. What if we add a new award? Remove an old one? Add some new "flavor text"? I don't think we are on the same page here.

Replying to jpschewe:

[... lots of talk about possible tools ...]

The notional work flow I have in mind is that someone (Norm or I) write the awards script, using some pre-defined or parameterizable queries to fill in what gets pulled from the server/database. Things like, "top 'n' in category 'y'".

It occurs to me that if this works, and we can come up with a good method for generating PDFs that also does HTML (live via AJAX?), we could use it to redevelop/design the rest of the system too - the scoreboard and brackets...

Realize that what we do for display right now is already a template. I'm very hesitant to replace all of the displays we have with a generic template library mechanism when we have one that works right now.

How is it a template if someone like Norm can't get at it? When I use the word template, it's something that someone who doesn't know programming can write. Like a mail-merge template, with special markup to tell the system what to fill in "here" and "here" and "here... What do you mean by template?

This is referring to Jeremy's idea of replacing the current brackets and scoreboard with a generic templating engine. What we have already is a template, we write some HTML code and then Java fills in the dynamic data and the combined result is then displayed on the screen.

Technically, that was my idea. I still think it's a good one. Anything we can do to minimze the number of chunks of custom code, and allow us to change the design over time, the better.

So it looks like the outcome here these actions: 1. make sure we can generate HTML to display the finalist schedule

insert "nice looking" in there before "HTML"

1. create the ability to generate an HTML display for during awards, this will involve uploading pictures and entering team number information or selecting from a list. This should be able to be controlled in a reasonable fashion, likely from another computer like we do for the brackets.

Lowest priority.

1. Create the ability to generate a PDF report for the awards script

That can change year by year, and may even differ slightly form tournament to tournament. It certainly is different between "normal" regionals, non- advancing, and state.

[jpschewe]

Replying to eengstrom:

Replying to jpschewe:

Replying to eengstrom:

The only two things I can think of that we want to display now [ that we don't already display ]are: 1. callbacks for finalist judging (at state) 2. award nominations/winners ppt show - complete with pictures of the teams - Sara V. has put this together (and pushed the buttons) in past years. (only at state)

I think those are the main ones we've been worried about. If the schedule is generated properly I think we already have something to display, or will with some minor changes to the finalist scheduling code. The display during the awards is the big one.

Have something, yes, but if you don't mind, it's really ugly. It needs a facelift, minimally.

Agreed that it could be prettier. The first priority was to get something functional. The following tickets are open for updates: 212, 216, 211, 62, 64, 65 (might be able to ignore), 126.

The first thing I really want is the awards scripts, and those never see the light of the projector - it's only for my consumption (or others giving awards).

And we should be able to generate that PDF pretty easily given the basic layout of the awards script and then having your or Norm answer some questions on a web page that then generates the PDF, just like the finalist scheduling.

But what about the words around the awards script. It changes each year. it's long. I don't want to have to have your (or worse me) "program" it in. Take a look at it in the dropbox folder.

That sounds like you would need a programmer. I could see them being filled in by a non-programmer fairly easily with some forms.

Forms? Web forms? That sounds like a lot of programmer work, and would have to chnage from year to year, likely.

Forms that are already written and that you or Norm fill in.

Sounds inflexible. What if we add a new award? Remove an old one? Add some new "flavor text"? I don't think we are on the same page here.

This is why we're trying to work out requirements. See ticket:126 which has existed for quite some time to do this and it's assigned to you.

Replying to jpschewe:

[... lots of talk about possible tools ...]

The notional work flow I have in mind is that someone (Norm or I) write the awards script, using some pre-defined or parameterizable queries to fill in what gets pulled from the server/database. Things like, "top 'n' in category 'y'".

It occurs to me that if this works, and we can come up with a good method for generating PDFs that also does HTML (live via AJAX?), we could use it to redevelop/design the rest of the system too - the scoreboard and brackets...

Realize that what we do for display right now is already a template. I'm very hesitant to replace all of the displays we have with a generic template library mechanism when we have one that works right now.

How is it a template if someone like Norm can't get at it? When I use the word template, it's something that someone who doesn't know programming can write. Like a mail-merge template, with special markup to tell the system what to fill in "here" and "here" and "here... What do you mean by template?

This is referring to Jeremy's idea of replacing the current brackets and scoreboard with a generic templating engine. What we have already is a template, we write some HTML code and then Java fills in the dynamic data and the combined result is then displayed on the screen.

Technically, that was my idea. I still think it's a good one. Anything we can do to minimze the number of chunks of custom code, and allow us to change the design over time, the better.

I'm open to someone coming up with a working example.

So it looks like the outcome here these actions: 1. make sure we can generate HTML to display the finalist schedule

insert "nice looking" in there before "HTML"

1. create the ability to generate an HTML display for during awards, this will involve uploading pictures and entering team number information or selecting from a list. This should be able to be controlled in a reasonable fashion, likely from another computer like we do for the brackets.

Lowest priority.

1. Create the ability to generate a PDF report for the awards script

That can change year by year, and may even differ slightly form tournament to tournament. It certainly is different between "normal" regionals, non- advancing, and state.

Yes, agreed. This should probably be over in ticket:126.

[jpschewe]

I think we are talking cross purposes and missing the point. Please let me clarify as best I can. The two highest priority "reporting" needs for next year are:

1. finalst scheduling and presentation
2. awards script generation

Note that NEITHER of those is the "awards presentation (powerpoint)" that we (sarah) does only at state.

Regarding finalist scheduling and presentation, there are indeed several things that could / should be fixed:

Replying to jpschewe:

Replying to eengstrom:

Replying to jpschewe:

Replying to eengstrom:

1. callbacks for finalist judging (at state)

I think those are the main ones we've been worried about. If the schedule is generated properly I think we already have something to display, or will with some minor changes to the finalist scheduling code. The display during the awards is the big one.

Have something, yes, but if you don't mind, it's really ugly. It needs a facelift, minimally.

Agreed that it could be prettier. The first priority was to get something functional. The following tickets are open for updates: 212, 216, 211, 62, 64, 65 (might be able to ignore), 126.

All of those tickets have relevance to generating an optimal, useful, pretty and printable schedule. However, none of those tickets have any relevance to generating an awards script, which is what I was hoping for when I suggested we look into a templating mechanism (this ticket).

This is why we're trying to work out requirements. See ticket:126 which has existed for quite some time to do this and it's assigned to you.

I think you must have some other ticket in mind there. ticket:126 is all about coloring the finalists schedule. I think you must have meant ticket:176. Yes, that's what drives my interest in a templating mechanism. In a sense, this ticket is more about that than replacing the current reports with new templates.

So, for the purpose of clarity, I will stick to talking ONLY about what is needed from a templating facility as it pertains to supporting the generating of a awards script.

The requirements for this templating mechanism, whatever it is, are:

• easy to modify without Jon or Jeremy or Dan or even me. Norm or someone like him needs to be able to do it.
• requires minimal human input the day of the tournment.
• may have purely subjective categories to specify (i.e. innovative design)
• In general does NOT need to be modified the day of the tournament.
• pulls as much as possible from the database for each of the numeric categories.
• remembers / uses the fianlists / call-backs for "nominated" teams for the state awards script.
• handles divisions properly - arbitrary divisions at some tournaments (like state) need to be "ignorable."

I'm sure there are others. In general, think "mail merge" like capabilities.

I will repeat what I said earlier:

The notional work flow I have in mind is that someone (Norm or I) write the awards script, using some pre-defined or parameterizable queries to fill in what gets pulled from the server/database. Things like, "top 'n' in category 'y'". That can change year by year, and may even differ slightly form tournament to tournament. It certainly is different between "normal" regionals, non-advancing, and state.

Does this help clarify what I was asking for here?

[jpschewe]

With regards to Eric's award script use case, what about a combination of Velocity and a glorified/simplified version of Markdown that we then render to PDF? First google result for an existing library is Pandoc, http://johnmacfarlane.net/pandoc/, but that's a command line tool. Or might it be worth it to create a syntax of our own to simply pull attributes from an object in the DB (instead of Velocity)? i.e. {@fll store type=team criteria=winnerof:Performance} - pull top team who set top performance score (no output) {@fll =teamnumber} - print the team number of the team we pulled above

(idk, made it up just now)

[jpschewe]

Replying to jjkoletar:

With regards to Eric's award script use case, what about a combination of Velocity and a glorified/simplified version of Markdown that we then render to PDF? First google result for an existing library is Pandoc, http://johnmacfarlane.net/pandoc/, but that's a command line tool. Or might it be worth it to create a syntax of our own to simply pull attributes from an object in the DB (instead of Velocity)? i.e.

Ignoring the tools in question, which I have not looked at,

{@fll store type=team criteria=winnerof:Performance} - pull top team who set top performance score (no output) {@fll =teamnumber} - print the team number of the team we pulled above

Reasonable. another completely made up example:

Division: Lakes
{@fll store type=team criteria="division=Lakes" sort="Programming:score"}
{@fll =teamnumber[1]} -- {@fll =teamname[1]} (score: ={@fll =score[1]}
{@fll =teamnumber[2]} -- {@fll =teamname[3]} (score: ={@fll =score[3]}
{@fll =teamnumber[3]} -- {@fll =teamname[3]} (score: ={@fll =score[3]}
Division: Woods
{@fll store type=team criteria="division=Woods" sort="Programming:score"}
{@fll =teamnumber[1]} -- {@fll =teamname[1]} (score: ={@fll =score[1]}
{@fll =teamnumber[2]} -- {@fll =teamname[3]} (score: ={@fll =score[3]}
{@fll =teamnumber[3]} -- {@fll =teamname[3]} (score: ={@fll =score[3]}

store the teams in division Lakes (then Woods), sorted by programming socre. then, print the top three in each division. Note the interspersed literal text.

Note that I don't care about the exact syntax that much, except that it needs to be reasonably clear to a non-programmer. i.e. not sql or anythying like that. I'm already venturing close to the line with my example.

[jpschewe]

Replying to eengstrom: Perfectly valid, but before we hammer out a syntax, we need to weigh whether or not it's worth it to use Velocity. Pros to Velocity: Existing FOSS library Can call most, if not all, methods in Java Allows for complex stuff Cons to Velocity: Complex, not user-friendly syntax You must use some SQL unless we made a bunch of helper methods and objects

[jpschewe]

• attachment set to Regional BlankAwards - 4WEB.doc

filled out example awards script.

[jpschewe]

Replying to jjkoletar:

Perfectly valid, but before we hammer out a syntax, we need to weigh whether or not it's worth it to use Velocity.

I don't mean to decide on an exact syntax, but the clarity and ease of use of the syntax needs to be there.

Pros to Velocity: Existing FOSS library Can call most, if not all, methods in Java Allows for complex stuff Cons to Velocity: Complex, not user-friendly syntax You must use some SQL unless we made a bunch of helper methods and objects

I leave that largely to you. I would rather enumerate examples of things that I want and let you decide what is the best tool for the job.

I have attached a sample awards script and will let you infer the examples from that.

[jpschewe]

OK, so this is now just about templating for the awards script? Which would then replace ticket:176?

Jeremy, right now everything is in Java and that makes it easy to install as you just need a JVM and everything just works. Please try and stick to such tools otherwise we're not likely to be able to use it. As far as using something like Velociy, I think you're a way too low a level for this discussion. Norm and Eric are not going to be editing velocity templates. I've done this and while Eric is capable (although probably out of practice), Norm is not.

Eric, how about a workflow similar to how the finalist scheduling works where you and/or Norm are walked through a list of questions to answer about the awards script (teams, award names, number of teams, etc.) and then that generates a PDF? The implementation of this may be custom code OR it may be a generic templating library.

Once we've done this for the awards script we can see if there's a way to use the same method for other aspects of the system.

[jpschewe]

Replying to jpschewe:

OK, so this is now just about templating for the awards script? Which would then replace ticket:176?

Yes and no. This started as "find a (java-based) report templating mechanism" which could be used for satisfying ticket:176 as well as perhaps other reports that we don't currently generate or even as a replacement for the reports we do generate. I had imagined it as a possibility for the finalist callbacks and the awards current powerpoint.

Suggestion, think more broadly, though use the awards script as the first instance, with other existing reports as secondary.

Jeremy, right now everything is in Java and that makes it easy to install as you just need a JVM and everything just works. Please try and stick to such tools otherwise we're not likely to be able to use it. As far as using something like Velociy, I think you're a way too low a level for this discussion. Norm and Eric are not going to be editing velocity templates. I've done this and while Eric is capable (although probably out of practice), Norm is not.

I read this as "stick to Java and Java libraries". Hopefully you didn't mean we can't use additional libraries.

Eric, how about a workflow similar to how the finalist scheduling works where you and/or Norm are walked through a list of questions to answer about the awards script (teams, award names, number of teams, etc.) and then that generates a PDF? The implementation of this may be custom code OR it may be a generic templating library.

Sorry, no - that's too much work. It needs to be canned so that when we have all the data in the database, out pops the report. At that time of the day, we don't have the time to fiddle with entering very much data to generate a report.

[jpschewe]

Replying to eengstrom:

Replying to jpschewe:

OK, so this is now just about templating for the awards script? Which would then replace ticket:176?

Yes and no. This started as "find a (java-based) report templating mechanism" which could be used for satisfying ticket:176 as well as perhaps other reports that we don't currently generate or even as a replacement for the reports we do generate. I had imagined it as a possibility for the finalist callbacks and the awards current powerpoint. Suggestion, think more broadly, though use the awards script as the first instance, with other existing reports as secondary.

Sure, but we need to have 1 working first and the awards script and the finalist callbacks are VERY different documents.

Jeremy, right now everything is in Java and that makes it easy to install as you just need a JVM and everything just works. Please try and stick to such tools otherwise we're not likely to be able to use it. As far as using something like Velociy, I think you're a way too low a level for this discussion. Norm and Eric are not going to be editing velocity templates. I've done this and while Eric is capable (although probably out of practice), Norm is not.

I read this as "stick to Java and Java libraries". Hopefully you didn't mean we can't use additional libraries.

Yes!

Eric, how about a workflow similar to how the finalist scheduling works where you and/or Norm are walked through a list of questions to answer about the awards script (teams, award names, number of teams, etc.) and then that generates a PDF? The implementation of this may be custom code OR it may be a generic templating library.

Sorry, no - that's too much work. It needs to be canned so that when we have all the data in the database, out pops the report. At that time of the day, we don't have the time to fiddle with entering very much data to generate a report.

Eric, you are going to need to provide some input as you've asked for the ability to specify judges awards and other random awards that don't exist anywhere else. All I'm saying is that we provide a workflow where you get to choose anything that I can't assume from the database.

[jpschewe]

Template source wise, I think a form of Markdown rendered to a PDF would be best, as it's best suited. And Jon, I asked about Velocity with the intention of "roll {@fll} ourselves" or use an existing library.

I think the first steps, regardless of the specific use case, would be to work on this document syntax, and just start as plaintext in -> plaintext out. I can work up from there.

[jpschewe]

Velocity can work to generate HTML, but I really doubt it can be used to easily generate a PDF, unless you find someone that has already written a PDF library integrated with Velocity.

Go for creating the plaintext version and let us know how it works. Personally I think that we just do a workflow to ask the user for the questions that need to be answered for the awards script and then generate a PDF like we currently do for reports.

[jpschewe]

• description modified (diff)
• summary changed from PDF (or PPT/Word) templating / reporting mechanism to printable, user (non-programmer) templating / reporting mechanism (e.g. for awards script)

Replying to jpschewe:

Go for creating the plaintext version and let us know how it works. Personally I think that we just do a workflow to ask the user for the questions that need to be answered for the awards script and then generate a PDF like we currently do for reports.

I think you are still missing the point of a template. I know there are some elements that don't yet exist in the database, but that doesn't mean that a template is not necessary. The primary example is for a user (aka non- programmer) templating mechanism is so that the awards script can be specified ahead of time (weeks, days, hours) before a tournament. What I don't want is something that only Jon can change and requires java or java-script programming.

[jpschewe]

Migrate attachment

[jpschewe]

• Priority: minor --> 4

[jpschewe]

A reporting library like JasperReports (http://community.jaspersoft.com/project/jasperreports-library) may be helpful here.

[jpschewe]

• status: assigned --> open
• Milestone: 2013 Season --> 2014 Season

[jpschewe]

@jjkoletar How are things coming on this task?

[jpschewe]

@jjkoletar any updates in this?

[jpschewe]

I'm using Apache FOP for reports now. This allows the option of specifying an XSLT and an XML file to create the XSL-FO file that is an input to the PDF rendering. This may be a reasonable option.

[jpschewe]

Issue #211 for the awards script has been implemented and it uses Velocity to handle the parameters. This isn't the completely generic templating language one desires for this issue, but it's a start.