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.
Related
I am brand new to pdf generation or rendering. I am working on a application to replace iText and create kind of a RESTful endpoints using any Java related PDF APIs.
The library should be able to convert images and.., others to PDF.
Read/fill the data from PDF programmatically and also merge.
Also, if we can host it ourselves that would be the best choice.
Could you please provide some insight into this?
Not exactly a "Java related PDF API" but since you want to go REST anyway:
We use a headless Chrome in a docker container for generating PDFs. A good starting point is hc-pdf-server. We use it as an internal service using REST.
Note that this way, documents need to be designed using HTML and CSS. Also, you need to use a template engine in order to insert contents into your documents. We use Mustache. It is simple and does the job.
I am new guy to Demandware and I am switching from Magento to Demandware.
Demandware is not opensource I am not getting proper tutorials, stuff to understand the concepts of it.
I am from Magento so I know the Magento MVC structure.
But in Demandware we have different concepts like pipelines, pipelets, ISML scripts, ECMA script, DW scripts etc.
I want to know the MVC pattern of Demandware.
How it works and what are the basic concept I need to concentrate?
I would suggest to request a Demandware XChange account as soon as possible for you, so that you get access to the Demandware community portal and also to the API documentation.
In short:
Models are Demandware Forms and Demandware API objects
Controllers are Demandware Pipelines (there are JavaScript Controllers that are recently released, you may find these easier to understand if you have Node.js experience). These can call DW Scripts (DemandwareScript is based on ECMAScript standard 5.0 for JavaScript with some extensions like E4X and optional types)
Views are the isml templates. You should avoid including a lot of logic in them, either with isml tags like isif, isloop, etc. or with isscript.
Any further questions - let me know.
Hope this helps,
Zlatin
I hope you'll be able to avoid pipelines and dwscript. Those are a bit older. The most recent version works with plain old JavaScript, with pipelines being replaced by controllers.
Be aware that the underlying JavaScript engine is Rhino, which isn't really modern.
The Demandware documentation is open source now anyone can access to without having an exchange account it has the latest SFRA(javascript) based concepts as well
here is the link for the docs
Demadware Documentation
Demandware is very much designed around the MVC concept (in theory). The pipelines are basically your controllers and each pipeline filename (the xml file) is the first part of the URL and the start nodes inside the pipeline are the second part of the URL that basically represent the controller (eg Cart.xml has a start node called Show, so the url is Cart-Show). At the end of the pipeline flow chart is, usually, an interaction node to that links to an ISML file, those are basically the View and are HTML with some minor Demandware-specific markup.
Typically in the MVC world you try to prevent putting business logic in the views, however if you use SiteGenesis as your starting point you'll find that not to be the case on most of the pages. If you switch to using Javascript Controllers instead of Pipelines, then it'll be closer to the Magento style of MVC (but using NodeJS-like syntax).
I want to make an extension that injects videos on product pages.
I already read a lot of documentation in Magento website but, sincerely, I have no clue where to start. What's the difference between Magento Extensions and Widgets? Can I develop my extension using only JavaScript? Do I really need to use PHP to develop one?
So many questions, can't find a focus. Can you please share a simple follow trough for me to read on? Thanks.
Credits : Marius
https://magento.stackexchange.com/questions/8344/how-to-write-a-custom-extension/8345#8345
Here is what I usually do:
Always develop with error_reporting on.
Always develop with isDeveloperMode set to true. Just add SetEnv MAGE_IS_DEVELOPER_MODE 1 to your httpd.conf file (or corresponding file for nginx or something else)
If the extension is linked to a core functionality add the
dependency in the declaration file <depends><Mage_Catalog /></depend>
If the module is for community use, use community as codepool to
give the developers the chance to override some classes without
modifying the code directly
Put your frontend design files in app/design/frontend/base/default
to make them available for all themes.
Put your admin design files in
app/design/adminhtml/default/default and do not change the admin
theme. I may want to change it in one of my modules.
Prefix your layout file names and template folder name with the
company name to make it easier to isolate them.
easylife_articles.xml and app/design/.../easylife_articles
Put your static resources (js, css, images) in a similar folder as
the template files easylife_articles/images/doh.png
Attach a simple text file with how to uninstall the extension: What
files need to be removed, what tables need to be dropped, what
config settings need to be removed from core_config_data table.
Do not write queries directly in models, blocks or helpers, use a
resource model for that.
Do not write queries using the table names directly Select * from
sales_flat_order where .... Use a Zend_Select and transform the
table names using ->getTable('sales/order').
Use the base url to include js files in template. Wrong
<script type="text/javascript" src="../js/some.js"></script>.
Right <script type="text/javascript" src="<?php echo Mage::getBaseUrl('js').'some.js'?>"></script>
Do not rewrite classes unless is necessary. Use observers and if
it's not possible use helper methods that receive as parameter and
instance of a class that you wanted to override. Wrong:
Override Mage_Catalog_Model_Product to add the method
getProductArticles(). Right. In your helper add
getProductArticles(Mage_Catalog_Model_Product $product)
If you override classes put a list of them in a readme.txt file
Use the default admin path for the admin section of your module.
Wrong admin url articles/adminhtml_articles/index. Right admin url admin/articles/index
Add ACL for your admin sections. I may want to restrict access to
some of the admins.
Do not add an other js framework (jquery, mootools, ...) if it's not
necessary. Write you code in prototype.
Make you template html W3C valid (this is for OCD developers like myself).
Do not put images in the media folder. Use skin. The media
folder usually is not versioned and this makes it harder to move the
website on different environments.
Test you extension with flat catalog on and off. In order not to double the development time use Chaos Monkey
Test your extension with cache on and cache off.
Avoid using uppercase letter in the module and class names. If not
properly tested this may cause issues on different OS. This is more a recommendation, not a 'must'.
Dispatch events in your code to make it easier for developers to
alter the functionality.
Follow the same coding standards that Magento uses and comment your code.
[Edited] Do not use php short tags (<? $this->doSomething() ?>). Use full tags (<?php $this->doSomething()?>). Also don't use short echo tags, yet. (<?="D'oh";?>). Use (<?php echo "D'oh";?>)
Translate your texts using $this->__ and add the locale translation file with your texts (app/local/en_US/Easylife_Articles.csv) at least for en_US language. Not all
websites are build in English and the identification of texts to
translate is time consuming.
If you sell an extension offer at least basic support. Or at least
answer the support e-mails you receive.
Do not make constant calls to your servers through your extension for licence validation. Once, at installation is more than enough (I don't like this approach either, but it's better than to make calls all the time).
(Inspired by this question)
Develop with the log activated and from time to time take a look at
the var/log/system.log file. The errors listed here are not shown
even with developer mode on. If there is at least one error you end
up with a large log file after a few months of running the extension.
If your extension affects the checkout process or the orders in
some way, make sure it works with multi-shipping, or if it
shouldn't work with multi-shipping, make sure it doesn't affect it.
Do not replace the default Admin Notification bar (or feed URL). If
I'm interested on what you have to offer I will subscribe to your
newsletter. Let me see what Magento has to say. It's more important
to me.
If you encrypt your code files with Ioncube (or something
else)...well...I just hate you and I hope your business goes bankrupt
That's what have so far. I will add more as soon as I think of something else.
You will definitely need XML and PHP, because this is mainly what Magento is built on.
Additionally to the official documents, there are a lot of helpful and very diverse tutorials out there that explain the mechanics of Magento. A web search helps, and I can recommend everything by Alan Storm, for example this litte module: http://alanstorm.com/magento_list_module
As soon as creating an extension works for you, you will also find a lot of tutorials on how to alter the product-view, or you can then post a more specific question here or on magento.stackexchange.com.
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.
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