I'm looking to generate docx and pdf documents in my java application. The best, most cost effective solution seems to be xdocreport - I've started using it and it's good.
However, xdocreport doesn't seem to allow reuse of common sections across documents.
Eg.
I want to create two documents - order and invoice. Both have a customer section which should be identical. It would be nice if I could maintain a single customer template that can be applied to both documents.
Are there any libraries (free or paid) that have this functionality.
The commercial product Docmosis can create DocX and Pdf and has an inert/merge capability meaning you can put common content into a template and merge/reference/insert with other templates. It has a Java API and you can try the cloud service without having to install anything to see if it suits your purposes.
Please note I work for Docmosis.
I hope that helps.
Related
I plan to use this template on my website for my spring boot web application:
https://github.com/puikinsh/gentelella
I have downloaded it and plan to just customized the pages to suit my needs. However, upon downloading it has a lot of folders one of which is vendors which contains a lot of js libraries amounting to 87.1 MB. I'm certain I won't be needing everything, my website will only contain a few CRUD pages and that would be it.
How should I use this template? Isn't there a simple example page that I can use and then just add the stuffs that I need one-by-one? instead of using all these files and deleting the ones that I won't be needing (I don't even know which to delete)?
Sorry if this is a noob question. But I hope I make sense.
Any help appreciated.
How are people managing multiple API versions with API Blueprint?
It doesn't seem that the format supports version sections within a single file, so I'm left thinking that multiple files with indicators in the filename are the best option.
We want to leverage the tools to create a central mock-server and doc commons, and will need to handle evolving multiple versions of each API.
Managing multiple versions via branches seems inconvenient for us, so we render the entire document with multiple versions of APIs in one page. Our users need to be able to read both versions by just prepending v1 or v2 in front of the URL. So, we have a node app that handles the documentation requests and renders the doc via aglio node module.
The following is how we organize the docs.
Users can request /docs/en/spec.
The en part determines the language of the document as we support different languages.
Because the entire document is pretty huge we split it into files based on the Blueprint Group (the thing that starts with # Group GroupName)
When a request comes in, we first look if we have previously compiled the doc and have a cached version, so we don't recompile every time (it's pretty intensive work especially when the doc is large).
If we have no cached version, we read all *.md files in the docs/en directory.
Sort the filenames alphabetically, concat their contents, and pass to aglio which produces a nice html content. We cache this content into a file and later pipe it to the client on each request.
The UI provides the table of contents (side menu on the left) which has, for instance, the following format.
Auth
Projects
Project Users
...
Groups
Groups v2
Now each Group of APIs has a distinct URL which is prepended with /v1 by default. When we introduce a new version of a specific API, we create a new # Group Groups v2 which is prepended with /v2. This way our users can see and choose multiple versions of the APIs in one page.
The nice things about the aglio node module is that it provide multiple themes for the UI which provides a nice navigation so that our users don't feel the page is too overloaded. Among the themes you can choose either single-page UI or multi-page UI where on selection of the API the page with the corresponding API is loaded and the URL is changed.
Implementing this logic is very simple. Hope this helps.
There is another idea which we are considering right now but haven't started just yet. It is to avoid splitting APIs into different # Groups and instead modify the Jade template used by aglio and make sure it supports multiple versions out of the box.
It might be best to version the blueprint file in a versioning repository and treat different branches as different API versions. You can even have the blueprint in the same repo/branch as the API server implementation.
If you're versioning using GitHub, Apiary can connect to GitHub and you can setup different branches to be picked up by different documentations in Apiary.
How can we handle pages with different designs when there is a pdf rewriter that is inbuild with Adobe Experience manager.
I know that there is a file page2fo.xsl which automatically generates pdf and we need to specify the rules in page2fo.xsl. But the website im working on is not just one design it is in different countries and different languages with their own designs.
In this situation how can we convert the html to pdf by just giving url as .pdf.
Do we need to write xsl for every design>?
Do we have any mechanism that will handle this situation in Adobe Experience Manager that comes with Apache FOP?
If there is any mechanism can you please give the sample of it to handle different designs?
I had a look into PDF generation with the page2fo.xsl and was even in contact with Adobe support regarding this. There can be only one file for all your designs as it is hardcoded in the final XSLTTransformer service running in OSGi. You can only overlay the configuration "/libs/cq/config/rewriter/pdf" with your custom one below apps, e.g.
"/apps/cq/config/rewriter/pdf" where you can reference a different page2fo.xsl thatn the foundation one. To support multiple designs in your XSL I would suggest a template matching the cq:designPath of your page. The only problem here you would need this property on every page and not rely on the inheritance like in the Edit UI.
Something along the line of:
<xsl:template match="*[contains(#cq:designPath,'/etc/designs/yourdesign')]">
<xsl:apply-templates select="yourdesign"/>
</xsl:template>
But I can guarantee you, it will be a mess and hard to maintain as you really only have this single file for all your custom XSLTTransformation.
I think in your case I would consider using another PDF Framework:
PDFBox from Apache. I made a PoC with it and it is painful for PDF creation as you need to know PDF Syntax
DynamicPDF: I was able to rewrite my PDFBox PoC within 2 days and even add features. So I would recommend it. You can download an evaluation copy and there are many examples around.
My server is Joomla 2.5, the version of CB is 1.8.1 and it runs on a MySQL database.
I would like to analyze the data in my database and create simple reports, for example: a list of all email addresses of all subscribers in a given period in time.
Is the right tool for this available in CB, in Joomla as an extension or should I go for a separate tool to dive into the database directly?
I searched in the CB site for reporting but didn't find a plugin for it, did find some 'advanced search' extensions for Joomla but they do not support reports as such.
I had to write custom components for this kind of requirements a few times, if you are familiar with Joomla coding I strongly suggest this approach it will be the most effective unless you need strong business intelligence, in which case you'd better switch to a bi tool.
The difference is: if you can pull all the data you need with just a few simple queries, write them yourself; if you need to analyze data, use a proper tool.
If you however are not a developer you might get away with a reporting tool, or a versatile CCK for Joomla.
Community Builder won't do this on it's own.
The easiest and quickest way to achieve this is to use an extension like ChronoForms and/or ChronoConnectivity which can help retrieve and display the required data from one or more tables.
ChronoForms: http://extensions.joomla.org/extensions/contacts-and-feedback/forms/1508
ChronoConnectivity: http://extensions.joomla.org/extensions/directory-a-documentation/directory/5661
These extensions make it easy to restrict a report to a particular group etc without having to write code.
There are plenty of examples in the chronoengine.com FAQs and the forum if you need help.
Probably the original question is not valide anymore, about an year later, but now there is a component that does what you need if you use ”registerDate” field as search criteria. The name of the component is JEmbedAll and you can find more information about that here: http://www.goldengravel.eu/jembedall-manual#.VVph_bvyNC0
Based on a specific application (bakery ERP), I need to create a new branch as a general purpose ERP with basic functionality (invoices, orders, work orders, customer communications...).
This new branch must be customizable for each client: print formats, application colors and icons/images, and restricted access to some application parts...
I've read about resource files for text/icons/image customization, but I need some help or alternatives, maybe defining an Interface to provide needed resources.
I use DevExpress components, so, print formats, and forms layout can be customized storing formats and layouts in files. However, main form has to be completely redesigned, and i wonder about the best way to do this. ¿this can be done with a little project containing the main form and implementing an interface providing custom images for buttons and other customizations?
Apart from layout customization, I need to restrict access to some parts of ERP for each customer, but behavior customization will be minimal or nonexistent, so, maybe I can personalize behavior with an xml config file for each customer.
Independently of my ideas, I thank you for any idea or comment about mu purpose: interface customization for each client, and minimal behavior customization. Don't need complex solutions like Workflow Foundation or completely pug-in based development.
If it's only format of prints and screen images, just use resource files or database configurations.
If you need functionality to be changed - use interfaces and inject their implementation via some framework, like MEF, for example.
And your English is good, no need to sorry