I was wondering if there’s a more efficient way to handle all the customizations of printing layouts that usually customers ask for.
The problem is quite obvious: if you sell your solution to different customers, you’ll have to find a way to handle all the customized print layouts.
What’s the best option?
Include all the different forms in the solution and choose the right one using a setting? It can drive you to a very crowdy solution, with lots of similar forms.
A print repository? A dedicated module? Could this be the answer? As it seems, it would solve the problem of messing up the solution with a ton of print forms and I’m really taking it into account.
What do you think? What’s your approach, in situations like this?
I think it may be a very good fundation for building a customer oriented report builder.
We already identified some needed improvements reguarding i18n and field names presentation for end users (sorry Bob, we have planned to report it to you before, but due to some lack of time it is still in the todo stack).
Definitely it is worth the time to test it, have a look.
What we tought it was important to add was presetting ‘dictionnary’ of i18n keys for each table in order to help (filter too) the end user to chose the right columns for her new report.
I think it may be a very good fundation for building a customer oriented report builder.
I know reporrwriter and I like it. But I was talking about something else: customer A wants invoice printed with logo on the upper left part of the header, font verdana 9 and doesn’t want to see the item code.
Customer B wants the item code, the logo must be included in the footer and the font must be Futura light 8 and so on…
I guess is quite a common situation, right?
I have run into the same problem and requested the ability to print elements true / false. It was suggested I move the elements off the form as a way to keep them from printing.
Yes, we have ask in the early days, for a developer lite (only allow simple editing of some forms) but untill now never made in.
What we do now, is provide, let’s say, 3 or 4 layouts. If the customer wants his own, we provide a custom layout in a module, for which they have to pay.
I have run into the same problem and requested the ability to print elements true / false. It was suggested I move the elements off the form as a way to keep them from printing.
Erich
It could be an option (especially with Servoy v3, where javascript effects will be retained when printing).
But it’s very difficult to think using such an option when you have to manage 10 different print layouts.
Maybe using a “setup” repository, where you store the info regarding coordinates of the various elements, the style to apply etc…Worth of a try, indeed.
I came up with a solution for a customer. It’s pretty convoluted, but here’s the concept - have a table that contains DATA for a report that you want: columns, order, formatting of each column, header HTML, footer HTML, etc.
Then you can use unstored calcs and report parts to make basically an unlimited number of combinations.
That way by simply changing the DATA in the settings, you can re-arrange column order, add/change columns, add/change data formatting of the data, etc.
c) Can I pass the dataset using SQL query in Servoy to JasperReport
from within the SERVOY form and returned back to SERVOY form
after finished printing the report ?
d) What Jasper components to install into Servoy in order for the two
systems run as an ‘embedded’ system.
HJK:
Yes, we have ask in the early days, for a developer lite (only allow simple editing of some forms) but untill now never made in.
What we do now, is provide, let’s say, 3 or 4 layouts. If the customer wants his own, we provide a custom layout in a module, for which they have to pay.
Not as nice if we want, but hey, it’s a start!
One of my options was to put all the printing layout in a module. This way, the proliferation of forms is not solved, but at least they don’t mess up your solution…
bcusick:
I came up with a solution for a customer. It’s pretty convoluted, but here’s the concept - have a table that contains DATA for a report that you want: columns, order, formatting of each column, header HTML, footer HTML, etc.
Then you can use unstored calcs and report parts to make basically an unlimited number of combinations.
That way by simply changing the DATA in the settings, you can re-arrange column order, add/change columns, add/change data formatting of the data, etc.
Do you use the calcs to generate the html code or for other purposes?
And, more important, do you consider it a usable technique for a +20 print layouts solution?
Riccardino:
Do you use the calcs to generate the html code or for other purposes?
And, more important, do you consider it a usable technique for a +20 print layouts solution?
Thanks
Exactly, those are options, but requires a lot work, and not open at all, for the end-user.
What we wanted to achieve is that a super-user can modify print-layouts in the client. (adjusting columns for your invoices, font-types, letter-heads, etc… not simple to do with calc’s, HTML, etc…)