Is there any plugin allowing user to create there own templates? So I use smth like
Templates.find(5).render(:val1 => val1, :val2 => val2)
There is a good plugin named liquid however it doesn't seem to be safe (user can drop database and so on).
Thank you.
Liquid is a very popular templeting system and is considered safe. In fact it was one of the design goals. From the documentation of liquid:
Liquid is a template engine which was written with very specific requirements:
It has to have beautiful and simple markup. Template engines which don't produce good looking markup are no fun to use.
It needs to be non evaling and secure. Liquid templates are made so that users can edit them. You don't want to run code on your server which your users wrote.
It has to be stateless. Compile and render steps have to be seperate so that the expensive parsing and compiling can be done once and later on you can just render it passing in a hash with local variables and objects.
The locomotive CMS use a gem called liquid that claims to do that. Check it here http://rubygems.org/gems/liquid.
Related
I have recently made the jump from developing using the Django framework to vue.js. One thing I am having a hard time wrapping my head around is the workflow for adding translations.
In Django, my workflow felt very intuitive:
Annotate my code with translation hooks.
Pull out the translation hooks into a .po (gettext) file
Translate the messages into the desired locale, i.e. do work in the .po file
Compile the .po file
In the context where all of my work needs to be translated, this workflow was very convenient and fool-proof.
I am excited about the move over to vue.js but I am afraid the difference in translation workflow might be a deal-breaker. Or perhaps, there is something I am missing? Here is my understanding of the vue.js/i18n workflow
Annotate my code with translation hooks. Unlike the Django process, I am using a Translation ID to link messages and translations.
Manually add those translation ids to a JSON file, e.g. en.json
Mirror that json file to that of a different locale, e.g., fr.json
I understand that I can use a tool like BabelEdit to manage the last step. While this seems like a great tool, it is the second step that I am really having a hard time getting my head around. Without a function like the django-admin/gettext makemessages this seems like it would be a tedious and inefficient task.
What am I getting wrong here? I imagine I am not the only one with these needs, so what are the translation workflows that are working for others developing with vue.js?
Thanks in advance.
I believe that you can use https://github.com/pixari/vue-i18n-extract on step 2. I think that BabelEdit can only help if you keep your translations as <i18n> section in your Vue components (in which case you will need https://github.com/intlify/vue-i18n-loader)
Is there a way to just use actual test data instead of writing all the fixtures for testing CakePHP website?
There is bunch of CakePHP plugins out there that doesn't use fixtures.
cakedc/cakephp-db-test: This doesn't use fixtures at all. Instead, it uses an additional template database that is initialized based on the file config/sql/test_db.sql. Also you can find a nice blog post regarding this plugin here.
pakacuda/cakephp-fixture-factories: This plugin also doesn't use any fixtures, but it uses factories to quickly whip up bunch of fake data on the fly, it also persist data.
Also you can check out awesome plugin from here.
I am relatively new to Grails and I am little disappointed with the way _form.gsp removed with field plugin in Grails 3. _form.gsp seemed to be good time saving option when we need to customize views with Bootsrap or materialize.
Now with grails 3, install-templates does not create _form.gsp. As per this documentation, we can achieve customization by creating _wrapper.gsp, _widget.gsp etc under view/_fields/default directory. But I am not able to find the example of such custom GSPs.
Also, let's say if I customize all the four GSPs (_wrapper.gsp, _widget.gsp, _displayWrapper.gsp, _displayWidget.gsp) will it generate actual code when we run generate-view command? I mean will it replace, f:all, f:table etc tag with actual code? If not then there is quite amount of work to do I guess. Because after we are confident about our domain class and tested all CRUD operation, we run generate-view command for creating all the domain specific GSPs. Then in most cases, we need to do some changes according to our requirement, like re-ordering the fields, hiding some of the fields
So in conclusion I have two goals:
Customizing default templates and start developing.
When I run generate-view, I do not want f:all, f:table etc abstract tags. I need actual fields in place so that I can customize generated views of domain.
If any one has achieved this, then please share the solution.
Grails 3 comes with the fields plugin by default. The templates used in Grails 2.x have been replaced in full. So, your goal 2. will be hard to achieve with Grails 3 it seems.
However, here is a helpful blog which explains how you can adjust some of the fields templates by replacing them in your project: http://blog.anorakgirl.co.uk/2016/01/what-the-f-is-ftable/
Similar to the description provided, you can place a modified _list.gsp template in folder in
/grails-app/views/templates/_fields/
Hope it helps.
In a Rails 3.1 app, one controller needs to have all its views compile whatever Sass stylesheets they might need per request using a set of custom variables. Ideally, the compilation must happen via the asset pipeline so that content-based asset names (ones that include an MD5 hash of the content) are generated. It is important for the solution to use pure Sass capabilities as opposed to resorting to, for example, ERB processing of Sass stylesheets.
From the research I've done here and elsewhere, the following seems like a possible approach:
Set up variable access
Create some type of variable accessor bridge using custom Sass functions, e.g., as described by Konstantin Haase here (gist). This seems pretty easy to do.
Configure all variable access via a Sass partial, e.g., in _base.sass which is the Compass way. The partial can use the custom functions defined above. Also easy.
Capture all asset references
Decorate the asset_path method of the view object. I have this working well.
Resolve references using a custom subclass of Sprockets::Environment. This is also working well.
Force asset recompilation, regardless of file modification times
I have not found a good solution for this yet.
I've seen examples of kicking off Sass processing manually by instantiating a new Sass::Engine and passing custom data that will be available in Sass::Script::Functions::EvaluationContext. The problem with this approach is that I'd have to manage file naming and paths myself and I'd always run the risk of possible deviation from what Sprockets does.
I wasn't able to find any examples of forcing Sprockets processing on a per-request basis, regardless of file mod times, that also allows for custom variable passing.
I'd appreciate comments on the general approach as well as any specific pointers/suggestions on how to best handle (3).
Sim.
It is possible. Look here SASS: Set variable at compile time
I wrote a solution to address it, I'll post soon and push it here, in case you or someone else still need it.
SASS is designed to be pre-compiled to CSS. Having Sprockets do this for every request for a view on a per request basis is not going to perform very well. Every request is going to have to wait for the compilation to be done, and it is not fast (from a serving-pages point of view).
The MD5 generation is within Sprockets, so if you are changing custom variables you are going to have to force a compilation on every single request to make sure that changes are seen because the view is (probably) not going to know.
It sounds as though this is not really in the sweet-spot of the asset-pipeline, and you should look at doing something more optimised for truly dynamic CSS.
Sorry. :-)
I'm new to MODx, but am quite impressed with its power and flexibility. There's only one caveat, and I'm hoping it's just because I don't know any better.
I'm a frontend dev, and I'm used to building websites of all sizes. But I usually work with files and version control. How would I keep this paradigm with MODx?
From my poking around so far, the only way I found to use an IDE, is to keep static files with my code, to later on copy/paste into MODx Manager. Far from ideal.
I'm aware that a lot of people use an "include" snippet, to include snippets, chunks, etc. Does this work for MODx specific tags? For example, if I include a file as a snippet, and I have a template variable defined in there (or a resource link), would that be properly rendered?
Also, is there a performance hit using a snippet by including a file, vs having the snippet code entered into MODx Manager?
Bottom line, how do you develop sites on MODx? Where do you enter your code? Is there a feature like the "Import HTML" but for snippets and chunks? Is there a way to create new Templates, Documents, Chunks, TVs, etc. without going through the Manager?
Thanks in advance!
there is a whole documentation site for developing in modx, http://rtfm.modx.com/display/revolution20/Home - though it mostly concerns extending it - not customization & modification. The short answer is no, there is no version control for your snippets & such, yes, you will have to maintain them manually. [I wish that was not the case]
Most of your php code will go into either a snippet or a plugin, and yes you can include static files in either of those resource types, no, I on't know if there is a performance gain/loss, but I would imagine "no" if your include is cache-able.
for the includes you can do something like this:
include_once $modx->config['base_path'].'_path_to_my.php_';
-sean
There is VersionX for revolution that will allow you version control of chunks, snippets, resources and so on.
There is package called Auditor that will allow you to implement version control in Modx
EDIT
Sorry just noticed your question is tagged Revolution, Auditor is for Evo. I don't think there's a solution available yet although I believe it is on the Roadmap