I'm willing to make an easy to use web-interfaced report builder. Basically, I would be like a big html form with some custom logic (if you check this box then that part of the form appears/disappears), uploading of images and rich text (bold, italic, colors). The user should be able to extract a pdf (that might be either server or client rendered). Some parts of the page should appear in the final pdf, some not. I need to control the page-breaks.
I could build a totally custom web-page for that and plug the result in a custom template in PDFjs, but I was curious if some solutions already exist for this problem. I've looked into jsreport and it's nice, but it is too complicated for my users to edit html directly. I would need more of a wrapper with simple fields. PDF forms, on the other end of the spectrum, are too rigid (an frankly, a pain to deal with) for my use-case.
To me, it feels like this problem is common enough, and should appear in enough companies that some rich template solution (or at least, general approach) might exist somewhere. Are you aware of such solution ? If not, what general tools would you use ? (PDFjs, Prosemirror, ..)
Thanks for your help !
Related
i was wondering if some of you experienced this problem, to generate pdf file from vue js or other js framework pdf file. I am not going to mention what libraries i tried, i am searching for a native way. Did some of you do something closer to this. The pdf needs to be generated from page that is is dropdowns and butons, so the functionality needs to remain in some way. Can you give me some proposals how to do it, with DOM or etc.
Where do you want to transform it into a pdf? On the server or in the browser?
In the browser, I'd recommend to simply allow the users to print it and use css to control what will be shown (using the print media query).
Then, instead of sending it to a printer, users can also choose to transform it into a pdf.
On the server you'll have to look for some libraries that offer this specific functionality and see which ones fit your usecase best.
Lastly, what do you mean with "the functionality needs to remain in some way"?
I'm not an expert in what PDFs can do, but they definitely cannot do enough to emulate a web-page – especially one that is complex enough to warrant using vue.js.
What exactly would you like to keep/have happen?
Let's say you want to be able to display some rich text in your app, and you want to design the backend API for that purpose.
Rich text can be :
paragraphs
Some bold or italic texts
titles from 1 to 6 weight
images
This is easy to do in HTML.
You could create the rich text I need, then store its whole HTML in the backend model's field.
Then retrieve it through your backend API as a HTML String and display it in a webview in your app or something.
But that sounds like a bad practice although I'm not too sure.
Please share your thoughts and experience about this.
Also, what would be a better practice for this kind of use case ?
It's usually not a good idea to store and display HTML as is, especially if it can be entered by a user (See HTML injection). If the HTML is always from a trusted source however it should be fine to store the HTML as is.
Some better alternatives would be to allow the users to enter markdown instead of HTML, that can then be converted to HTML when it is displayed.
If however markdown does not meet all of your criteria the HTML that will be stored and later displayed should be stripped of all possible malicious tags, for example <script> and <iframe>.
The best means of displaying HTML is likely some kind of web viewing component, which tend to be quite heavy by their nature.
What I would consider, in your situation, is a markdown component. The reason for this is markdown maps to NSAttributedString quite closely.
^^ All opinion, of course.
I'm developing a Rails web app using the contentEditable feature of HTML 5, in the style of Google Docs and others. This works well for simple typing, but breaks whenever the user tries to paste text from Word or another webpage. The resulting HTML will be littered with style attributes and will look like it was literally cut and pasted from the source.
I need to filter the HTML some way. This can be done client-side, giving a smooth interface for the user where pasted material fits instantly into my app's style.
Of course, the user can override my filtering. So to protect myself fully from tag soup hell, I would need to perform the same filtering again, server-side. This is similar to the form validation problem.
I don't want to duplicate the filtering logic in both jQuery (client-side) and Ruby (server-side) but I don't know if there's any good way to avoid it. So far I have identified two possibilities:
Implement all filtering server-side, access it from the client by AJAX. This will put a heavy load on the server.
Implement filtering fully in JS, run on client and on server through Node.js. I don't know if there is enough similarity between the two platforms to implement a shared filtering routine. Libraries like Cheerio look promising though.
Has anyone solved a similar problem before? I would appreciate any guidance to keep my app as DRY as possible.
I have a quite complex xsd file that describe some objects (it's not important, but it's the DATEX II standard)
Do you know if there is an automatic way to create an html form that act like a "wizard" to guide the user to create xml object as described in the xsd?
The answer to this depends on the intended user base, how you want your users to access your forms, and the technology stack you have in place already or you're willing to deploy.
If your users are quality control analysts, and so the intent is to have them use that generated UI to manage test cases, then a handful of commercial tools have this ability. A quick search on Google for terms such as "generate ui forms from XSD to test web services" should give you on first page the major players in this space (I won't name names to avoid conflict of interests). There are differences in how vendors approach this, that have to do with the time it takes to generate these forms from large bodies of XML Schema, which in turn translate into different degrees of usability. Given what I see in DATEX, from a complexity perspective, you may have a hard time to find a free tool for this...
If your users are rather data entry specialists, then the above are not the tools you want them to use. Without knowing much about your environment (I see your java-ee tag, but still not clear how it would relate to this task), one model could be a combination of InfoPath with SharePoint; while the process to generate the form is not fully automatic, it comes close to that. It is XSD driven, in the sense that at design time you drag and drop XSD on a design form, that allows you to build some really nice UI. Follow their competition on your particular technology stack and you may have your answer. Or, you can go to this site that lists XForms implementations; IBM's form designer, much like InfoPath, can use XML Schema for design, etc.
If this is for developers to get some XML, another alternative might also be to go with an Excel based (or SharePoint lists) approach and generate XML from that data (you give away cost to acquire something to build specific to your requirements tooling, here assuming people that are really familiar with spreadsheets instead).
Given how DATEX model looks like, you'll have to do some manual customizations anyway, if you plan to use the extensibility model, or if you choose to build different forms for different scenarios i.e. instead of one big form that'll give you all descendents for the abstract payloadPublication in some drop down, to just a specific, simple form e.g. MeasurementSiteTablePublication.
I know this is an old question, but I ran into this issue myself and couldn't find a satisfying open-source solution. I ended up writing my own implementation, XSD2HTML2XML. To my knowledge it is the most complete tool out there. It supports automatic generation of HTML forms from XSD, including the population of a form with XML data.
If you prefer an out-of-the-box solution rather than writing your own, please see my implementation, XML Schema Form Generator.
I'm trying to create a script to fill out a multi-page "form" that I have to fill out weekly (unemployment form actually), the 4th page ends up giving you a Checkbox and 2 Radio Buttons, all built by Javascript. When I navigate to this page using Mechanize I get html back without those 3 controls so I can't go any farther in the process.
Is this a common problem?
I'm filling out the form then just calling page = agent.submit(form, form.buttons.first) and it comes back without those controls built.
Mechanize is an HTML parser, not a JavaScript interpreter. If it's not in the HTML, there's nothing it can do. You need a "proper" browser. (By "proper" I mean one which can at least parse HTML, run JavaScript and ideally also interpret CSS.)
There are tools like Selenium & Co. that let you "remote-control" a "real" browser (Firefox, Internet Explorer, …) and there are efforts to build completely scriptable GUI-less browsers for precisely this use case.
Note: Depending on what country you are in, the unemployment agency may be in violation of anti-discrimination laws (especially if it's a government agency), so you could maybe force them to offer a JavaScript-free version of the form, but that's a) not a short-term solution and b) a topic for your lawyer, not StackOverflow.
Are the values of the generated form predictable? I often find it convenient to bypass all the individual form-helpers and just post to the form directly:
browser = Mechanize.new
browser.post(some_url, { field1 => val1, field2 => val2, ... })
You might want to look into using Watir if you're on Windows, or firewater on Mac/Linux or safariwatir on Mac only. All are basically the same code and are at the same site.
It's more oriented toward testing websites, but you can get at the content of the page using xpath, and from there proceed. Hopefully the browser will have processed the javascript for you and will return that. I've seen some browsers display the JS rendered HTML in their source view, and others don't, so I'm not sure what results you'll have.
As has been mentioned in other answers, you need to use something which drives a real web browser as there is currently no libraries capable of parsing that level of javascript (some can follow javascript redirects, but that is pretty much it). This would be ideal and easier to maintain.
If you really want to stick with the mechanize approach then you should simply be able to add the post field manually.
If they use a captcha to circumvent automated posting then you can need to resort to a simple decaptcha service (10 dollars for 2000 credits should be enough).
Lastly, it may be prudent to just not go through all this trouble.