In a VUE.JS 2 application I'm working on, there is a series of form fields dynamically generated from a JSON Schema. As the Schemas change so do the inputs. (We are using a modified version of this library : https://gitlab.com/formschema/native/tree/feature/new-architecture.
I'd like to attach a Basic WYSIWYG to a particular textarea that was dynamically generated. All the libraries I've come accross need you to manually add the Tag to the template with attributes. Since the form is dynamically generated this seems difficult to do.
Is there a simpler vuejs way to attach a WYSIWYG Editor to a textarea? Perhaps by linking it to a certain ID. The textarea comes prepopulated with data from an API, and that info would need to be included. Any insight is appreciated. I've looked at the following libraries with no success:
https://github.com/ckeditor/ckeditor5-vue
https://github.com/froala/vue-froala-wysiwyg
https://github.com/davidroyer/vue2-editor
Related
I'll change the template of the invoice pdf template in shopware 6.
The template self seems to be stored in the database in the table "document".
The pdf is generated by php.
Anyone knows, how to get a complete own customized template ?
The configuration in the backend is not enough.
Thank you.
I wrote an example Theme some time ago, that is extending the basic template: https://github.com/mnaczenski/SwagDocumentTemplate
The core template is located here:https://github.com/shopware/platform/blob/trunk/src/Core/Framework/Resources/views/documents/base.html.twig
So you can overwrite the file in your own theme like described in the documentation by extending the twig file and placing it in the right folder: https://developer.shopware.com/docs/guides/plugins/themes/theme-base-guide
Extend in Twig: {% sw_extends '#Framework/documents/base.html.twig' %}
Folder structure: /src/Resources/views/documents/base.html.twig
Generated PDFs are stored in the database due to German law, they can't be changed after generation. But new generated PDFs are based on the template.
The easiest way to customize your invoice templates is to use the WYSIWYG Document Editor. You can either customize an existing document or create a completely new document. Using one of the predefined document templates provides a good starting point for you to apply your customizations. But you can also start with a blank page.
With the visual editor, you can easily add new elements and variables and see your changes in the live preview. This will save you a lot of time in comparison to going back and forth hundreds of times between making adjustments in your Twig Files and generating new PDFs for testing.
Here is a YouTube Video, which shows you how easy and fast you can edit all your documents: https://youtu.be/fGBMDmVMPvA
I am the developer, which created the WYSIWYG Document Editor Shopware 6 App. Feel free to ask me any questions about the App. I am happy to help you.
i want to add an autocomplete function to work in one of my column suppose name.It is easy to do using items.but how can i do it in the report.
Since a report doesn't contain Apex items, you can't do this with the built in features. Ignoring any possible plugins that may already be available, you can do this with jQuery UI, specifically the Autocomplete widget. Apex already includes some of the jQuery UI suite, but you may need to download the Autocomplete widget from the jQuery website.
This will need some custom work on your end. This really isn't that hard if you know how to use jQuery.
Download the jQuery UI Autocomplete widget and include it on your page. You can put just the .js file for that in your Application Shared Items. I have the whole jQuery UI library in a separate place on the webserver because I use different parts for different projects.
Source in that widget in the page properties.
You'll need to create text items with apex_item.text in your report.
You'll need an On Page Load dynamic action to attach the Autocomplete widget to your text items.
For the autocomplete source, if it's short, you can just use a Javascript variable that you put on the Apex page. If it's longer or you need to find the list at run time, you can use a function that calls apex.server.process.
If your report has Partial Page Refresh turned on, make sure the DA in step 4 has Dynamic scope, not Static.
we are moving from content editor to experience/page editor as our primary editor interface and one of the fields we deal with is a raw multiline field for dropping custom script into the pages by editors. Eg campaign management, google tag manager or similar
Currently if I render a SC:fieldrenderer via webforms the script tags are becoming part of the dom on render.
What is the best approach to tackle this type of interface requirement via experience editor in SC7 webforms - it looks like sitecore isnt outputting to an input tag in order to supress and contain the code and is instead outputting to a span which is then flowing into the dom.
Thanks for any direction
I am working on a custom sitefinity module in which I need to add a custom field where I can select a Sitefinity Form from a list of existing defined forms on the backend. What is the best approach to do this? Precisely how should I approach in defining the field and making its UI?
Unfortunately when I select "Related Data" as field type, Sitefinity Form is not available in the list of built-in data types. The other option (advanced option) I see is a GUID (or array of GUIDs) field type among field types which suggest making a custom code.
CMS version is Sitefinity 8.2 and we are using MVC-based feather components as well as our custom MVC components to develop the website.
Anybody had similar requirement and experience on this?
I would probably create a custom field control. This can be streamlined by using Sitefinity Thunder (because there's a lot of boilerplate C# and JavaScript needed). Once that's in place, you can create a custom field of either type Short Text or GUID, and for the interface, you use your custom field.
In your custom field's code, you can do something like creating a drop down list, where the text for each option is the form name, and the value is either the "name for developers" field or the ID of the form. That way the input is always constrained to IDs pointing to Sitefinity forms. Then when you interact with your custom content items later, you can use this ID/name to look up the referenced form.
As an aside about Related Data: Indeed, that only refers to either built-in content types (blogs, news, etc.) or custom-build dynamic content types. You won't find things like Forms in there.
Context
Part of the administrator side of our application requires the user to edit various types of content, which involves using a rich text editor or using files to generate content that can be seen by the 'client side' users of the application. It's kind of a domain-specific CMS lite.
Because this 'content' can be used in various parts of the application, it is included as a seperate relation in some of our domain entities. We decided to make our own tag library that defines some form fields that can be used to edit this content when an administrator edits an entity that includes a piece of content.
Question
What we'd like to be able to do is the following.
<form:form modelAttribute=...>
<olo:content-editor path="content"/>
<!-- Other form fields for this entity -->
<form:.../>
<form:.../>
</form:form>
The olo:content-editor tag then generates a number of form fields based on what type of content is needed. This means it may (or, depending on the type of content, may not!) generate the filebased-content tag which contains:
<input type="file" name="file/>
Which can be used to replace the file associated with the file based content.
The problem is that the Spring docs indicate that the file upload requires the form to have the enctype to define that it's sending multipart form data. As the file upload is part of the tag and not the form itself, we find this is undesirable. We would like to be able to use our olo:content-editor tag in forms without having to change the form enctype attribute. Is this possible?
Possible solutions
We can think of two client-side hacks that may resolve our problem, but both seem to be rather ugly solutions:
Include a script in filebased content tag that changes the form enctype when it's loaded, so that it is always set to the appropriate type. (Very ugly.)
Submit the file data as a regular hidden form field, of which the data is set by using the HTML5 File API (administrators use a compliant browser. This seems far less ugly but still not an optimal solution.)