Mailing lists / lazarus / 2013-01
37 messages · 8 people · –
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Hello,
Please see in:
http://bugs.freepascal.org/view.php?id=23664
Thanks,
silvioprog wroteHello, Please see in: http://bugs.freepascal.org/view.php?id=23664
This cannot be fixed. Lazreport is not suitable for use in webapplications.
Some time ago, I started a new reporting engine exactly for this reason.
A well-designed reporting engine is independent of any widget set. (see e.g. jasperreports in Java)
Michael.
Michael Van Canneyt wroteSome time ago, I started a new reporting engine exactly for this reason.
And how far is your progress with that? Which reminds me that I should finally test the new database search provided in packages... -.-
A well-designed reporting engine is independent of any widget set. (see e.g. jasperreports in Java)
Fully agreed here. :)
Regards,
Sven
It is currently dormant; I had finished the looping logic, if memory serves well.
Michael.
This cannot be fixed. Lazreport is not suitable for use in webapplications. Some time…
2013/1/17 Michael Van Canneyt
Hm... I'll close the issue. Thank you Michael.
Your report library will be open source? If yes, I would like to collaborate on the development. :)
I've been thinking of creating a library for reports based on JSON, but to create something like this would take too much time.
And how far is your progress with that? Which reminds me that I should finally test the…
2013/1/17 Sven Barth
+1. :)
Regards, Sven
2013/1/17 Michael Van Canneyt Hm... I'll close the issue. Thank you Michael. Your report…
It will be open source.
I've been thinking of creating a library for reports based on JSON, but to create something like this would take too much time.
The storage format is not really the problem.
The looping logic is far more difficult :(
Michael.
It is currently dormant; I had finished the looping logic, if memory serves well. Michael.
2013/1/17 Michael Van Canneyt
I've been thinking of porting jsPDF for Free Pascal:
But, using inheritance, something like (a pseudo example):
VLabel.Text := 'Hello';
VLabel.Font.Style := [fsBold];
VMemo.Lines.Add('Line 1');
VMemo.Lines.Add('Line 2');
VMemo.Font.Align := faJustify;
...
pdf.LoadFromJSON(<JSON>); // or pdf.LoadFromDataSet
pdf.AutoPaginate := True;
pdf.AddPage;
pdf.AddObject(VLabel);
pdf.AddObject(VMemo);
pdf.AddObject(VImage);
pdf.Print('print.pdf'); // or pdf.Print to print as DataURIIt will be open source. The storage format is not really the problem. The looping logic…
2013/1/17 Michael Van Canneyt
Yeah! \o/
Hm... The code is in a repository? Could create a temporary repository on Github, after done, move it to the Free Pascal SVN.
2013/1/17 Michael Van Canneyt I've been thinking of porting jsPDF for Free Pascal:…
Before you code anything that already exists, look at: https://github.com/jepafi
It's more promising. All it misses is embedding fonts, and that should be easily added.
Michael.
This cannot be fixed. Lazreport is not suitable for use in webapplications. Some time…
I had a similar issue some time ago with, TAChart. It needed TCanvas to draw charts, but that was fixed by Alexander, if I remember correctly.
That's why I stopped looking for a report generator for my cgi apps. Now I rely on libHaru (http://libharu.org/), which is a C shared library with Pascal bindings that allows creation of PDF files.
The problem with libHaru is you don't create reports out of markup, but by code. In my case that's not a problem, because I'm the only one in charge of creating reports, a different story will be when the final user wants to create their own reports.
2013/1/17 Michael Van Canneyt I've been thinking of porting jsPDF for Free Pascal:…
libHaru is exactly that, and I can confirm it works with Unicode Fonts, and everything I need.
Before you code anything that already exists, look at: https://github.com/jepafi It's…
2013/1/17 Michael Van Canneyt
Yes, it's promising, but I would do something a bit more object-oriented, and less like PHP. :)
And yet I've been thinking in the following:
pdf.Filter(T<ProjectCodeName>PDFFilter);
pdf.Save('print.pdf');or ...
pdf.Filter(T<ProjectCodeName>XLSFilter);
pdf.Save('print.xls');And also would a design report (as IDE).
I had a similar issue some time ago with, TAChart. It needed TCanvas to draw charts, but…
2013/1/17 Leonardo M. Ram?
Very nice.
You could send a small example with this library to take a look? Thank you.
libHaru is exactly that, and I can confirm it works with Unicode Fonts, and everything I…
2013/1/17 Leonardo M. Ram?
Yes. I also need full support for UTF8.
2013/1/17 Leonardo M. Ram? Very nice. You could send a small example with this library to…
Yes, te attached file generates a report based on a TCollection containing the data for each page, it has a header, body (with many lines) and a footer. I also attached a small jpg showing the final report.
2013/1/17 Michael Van Canneyt I've been thinking of porting jsPDF for Free Pascal:…
silvioprog wroteI've been thinking of porting jsPDF for Free Pascal:
fpGUI also has a small PDF reporting engine. To see what it can do, take a look at the demo in <fpgui>\examples\gui\reporting
Some features:
* Text output (obviously)
* Text attributes (color, size, font, alignment etc)
* Image support
* Drawing primitives
* Headers, Footers
* Sections
* Grids
* Page numbers, Section numbers
* Page attributes (landscape, portrait, mixed, pages sizes etc)
* PDF attributes (eg: when file is opened go full screen or 2-up etc)
* Print Preview (this is dependent on fpGUI of course, but it is a separate unit, so isn't a problem)
It doesn't bind to datasets etc. You simply iterate whatever data you want, and write whatever to the PDF's canvas. This gives you the most flexibility and allows creating reports from anything (business objects, datasets, stringgrid etc).
Currently the PDF engine has very little dependency on fpGUI - a data type which could be easily redefined in the reporting unit itself, and some color utility methods, which again could be redefined in the reporting units themselves.
I'm using this PDF engine to generate rather complex reports in our commercial apps, reporting from tiOPF-based business objects. It works very well.
An French developer wrote and contributed this to the fpGUI project. Some classes and methods are still in French though, but if you look at the demo project and its demo reports, it is easy to figure out. We are still working on translating everything to English. If you do try it out and hit a problem, you are welcome to post questions in the fpgui.support newsgroup (see the website for details).
Regards,
- Graeme -
Well, I was looking at this too for a PDF backend.
Finally, it was the dependency on fpGUI that stopped me from using it.
If we can make sure there is no such dependency,
I'd very much like to have it in FPC itself.
Michael.
2013/1/17 Michael Van Canneyt I've been thinking of porting jsPDF for Free Pascal:…
Why jsPDF and no FPDF (https://github.com/jepafi/Free-JPDF-Pascal)?
Marcos Douglas
PS: or my fork https://github.com/mdbs99/Free-JPDF-Pascal
Why did you fork this ?
Michael.
Before you code anything that already exists, look at: https://github.com/jepafi It's…
Yes, I agree.
I have a fork here https://github.com/mdbs99/Free-JPDF-Pascal
Yes, I agree.
I have a fork here https://github.com/mdbs99/Free-JPDF-Pascal
Memleak and some minor fixes was done -- but not merged in the original project yet.
I want to codify a class more like FPDF (original PHP) to use the same documentations and another more "pascal-stylish".
https://github.com/mdbs99/Free-JPDF-Pascal
Marcos Douglas
Why jsPDF and no FPDF (https://github.com/jepafi/Free-JPDF-Pascal)? Marcos Douglas PS: or…
2013/1/17 Marcos Douglas
jsPDF have more reatures. :)
Yes, te attached file generates a report based on a TCollection containing the data for…
2013/1/17 Leonardo M. Ram?
Thank you very much, I'll see this... :)
Why did you fork this ? Michael.
Because the author do not have time to work in this project at moment (I sent a fix for a memleak and until now wasn't merged). I proposed to him codify a class following the FPHP stylish but he won't change the current code.
Marcos Douglas
Well, I was looking at this too for a PDF backend. Finally, it was the dependency on…
Nice!
Marcos Douglas
Well, I was looking at this too for a PDF backend. Finally, it was the dependency on…
Michael Van Canneyt wroteIf we can make sure there is no such dependency, I'd very much like to have it in FPC itself.
I'm sure something could be worked out. Like I said, there is actually very little dependency on fpGUI.
A quick browse through the code (see the src/reporting directory) I can see the TfpgColor type (simple record structure), 3 color extraction methods (Reg, Green and Blue), and one or two RTL wrapper functions for Unicode filename support - these will take about 20 minutes to fix and test.
Then there is TfpgImage for Image embedding in PDF's. The Image support was one of the last things to be added to the PDF engine. The PDF reporting already worked very well before Image support was added. Anyway, I'm quite confident that the TfpgImage usage could easily be abstracted out. TfpgImage is just a container for the raw image data.
Regards,
- Graeme -
This cannot be fixed. Lazreport is not suitable for use in webapplications. Some time…
2013/1/17 Michael Van Canneyt
[...]
Some time ago, I started a new reporting engine exactly for this reason.
When launched FPreport, I'll create a Brook's broker for it. :)
This cannot be fixed. Lazreport is not suitable for use in webapplications. Some time…
Michael Van Canneyt wroteThis cannot be fixed. Lazreport is not suitable for use in webapplications.
I am curious -- can you elaborate on the reasons for that? I can understand the dependency on the concept of widgetset, but why nogui is not sufficient?
As I remember, the most serious issue I encountered while porting TAChart to nogui
was inadequate font support in FPC, but we have LazFreeType now... (BTW, I should try LazFreeType in TAChart...)
Alex, could you try porting LazReport to nogui? AFAIR, the problem is the same as TAChart, it requires to draw somewhere.
leledumbo wroteAlex, could you try porting LazReport to nogui?
Aside: "Alex", "Alexey" and "Alexander" are very different names in Russian. Please do not confuse me by using the wrong name ;)
AFAIR, the problem is the same as TAChart, it requires to draw somewhere.
I have taken a look. Unfortunately, the LazReport turned put to be almost exactly equivalent
to old FastReport library (most units even still retain copyright header from there).
Which is bad news, becase FastReport/LazReport is, shall we say, not an example of proper design.
Most basic units, including LR_Class, use not only Graphics, but Forms, Dialogs, Menus, and more.
There are inexplicable things like
try ... except ShowMesage(...) end
calls to MessageDlg from the setter of TfrObject.Name property, etc. I see several possible ways forward here:
1) Add a lot of IFDEFs. In the general case, mass-IFDEFs are horrible idea, but this code is already a pain to look at, and selecting nogui widgetset is compile-time decision anyway,
so perhaps it is feasible.
2) Do a "slow rewrite", by progressively rfactoring and improving code, with gradual breaks of compatibility and
appropriate deprecation periods, until the code gets in decent shape. This is a "proper" way, but requires much work and time -- about a year for the dedicated maintainer.
3) Do a "fast rewrite" -- just throw away this code and use something else, or write it from scratch. This is basically what everyone else in this thread are suggesting. As much as I dislike "second system syndrome" (http://www.joelonsoftware.com/articles/fog0000000069.html), this might be a reasonable course in this case.
On Thu, Jan 17, 2013 at 6:52 PM, Michael Van Canneyt I am curious -- can you elaborate on…
Because I do not consider noGUI a valid solution.
It is a totally misguided concept.
I'm sure the lazarus devs had their reasons for introducing it, but it is one of their worst decisions ever (in my opinion).
They should have fixed the original problems properly: i.e. remove all erroneously introduced GUI dependencies, so nogui was not needed to begin with.
(I am aware that this might have taken more time)
Look at jasperreports in Java.
It's core has no gui dependencies, and that is how it should be.
Michael.
Aside: "Alex", "Alexey" and "Alexander" are very different names in Russian. Please do…
Which was exactly my conclusion when I looked at it, and so I started fpReport :-)
Unfortunately, time constraints are everything :(
Michael.
Aside: "Alex", "Alexey" and "Alexander" are very different names in Russian. Please do…
Alexander Klenin wroteOn Sat, Jan 19, 2013 at 4:17 PM, leledumbo wrote: > Alex, could you try porting LazReport to nogui? Aside: "Alex", "Alexey" and "Alexander" are very different names in Russian. Please do not confuse me by using the wrong name ;)
Well, there are people that prefer a shorter version of their name... For example I know a "Alexandra" which prefers to be called "Alex". :)
Regards,
Sven
Because I do not consider noGUI a valid solution. It is a totally misguided concept. I'm…
Michael Van Canneyt wroteI do not consider noGUI a valid solution. It is a totally misguided concept. I'm sure the lazarus devs had their reasons for introducing it, but it is one of their worst decisions ever (in my opinion).
Actually I think nogui is a valid workaround.
Of course, correct GUI/logic separation would be better, but it is much harder to achieve,
especially while maintaining backwards compatibility. For example, it took maybe two days of work to convert TAChart to nogui, and, while not pretty, it does work, as evidenced in this thread. At the same time, "correct" solution must wait for new FPC version, for even the first attempt,
and even then I am not sure it will be possible.
Which was exactly my conclusion when I looked at it, and so I started fpReport :-) Unfortunately, time constraints are everything :(
Yes, so it is conceivable that a "fast" rewrite will require two years while "slow" one could be done in only one year :)
exactly: a workaround.
I want a real solution.
"Aut Caesar, aut nihil."
Michael.
Because I do not consider noGUI a valid solution. It is a totally misguided concept. I'm…
+1
Couldn't say it better if I tried.
Regards,
- Graeme -
On Sat, Jan 19, 2013 at 9:14 PM, Michael Van Canneyt Actually I think nogui is a valid…
Alexander Klenin wroteActually I think nogui is a valid workaround.
They key point here is "workaround"
Of course, correct GUI/logic separation would be better, but it is much harder to achieve,
We become developers knowing that we will have tough problems to solve. That's the joys of developing (at least for me).
For example, it took maybe two days of work to convert TAChart to nogui, and, while not pretty, it does work, as evidenced in this thread.
And again, the key here is "not pretty". That doesn't bode well in any software.
Regards,
- Graeme -
