In NodeJS we have view engines (mustache, pug and etc.) and we can setup and use any of them. Does Perfect has any (default or installable) view engine with features like Layout Setting, Partial Views and other features?
I read about Perfect-Mustache in Perfect documentation, but I think it is not clarify how to use this, or how to separate views (.mustache or .html files) from other files, and how to render them.
There is an example to answer your question: Perfect-Blog-Mustache, a Perfect CMS demo:
https://github.com/PerfectExamples/Perfect-Blog-Mustache
Related
I've been studying sapui5 framework for some time now and I always used javascript views in my applications.
The question is - are there reasons why should I prefer xml views over javascript, if I should do it at all? If there are some, what are they?
If I want to start trying to write xml views, what is the best place to learn the basic syntax and where can I find API reference for controls created using xml? The SAPUI5 API is written for use with javascript.
Thanks.
Major reason, in my view, is strict separation of concerns. XML views, by their nature, preclude code. Your XML view is therefore strictly presentation logic - a great outcome for professional enterprise development. It also reduces the significant lines of code to code out the ui and thus improves readability and maintenance of code.
the reason I use XML views is because this is the standard approach of the Fiori apps by SAP. It creates a situation where developers only have 1 approach. Also to me they are easier readable.
Generally speaking I see that in the mobile library the xml views are used while in desktop usage js is still leading. On SCN you can find many similar questions.
The library of examples can be found in the same API page under tab EXPLORED.
Perhaps using the webIDE (which offers a local) install can provide a really good base for you to start development using xml based views.
Where you say the API is written for js views, this is true because the controls are written in JavaScript. Look at it this way if you have a namespace in your xml like xmlns:l="sap.ui.layout" any xml element prepended with l like <l:GridData ...
becomes a call to sap.ui.layout.GridData and if you look at the api for this control you can see what attributes you can add to this control / element.
Also if you have xmlns="sap.m" in your namespace block then anything like <Page /> <Table /> become sap.m.Page or sap.m.Table so the api is still a valuable resource and the explored section is great to see controls in action.
I am trying to use a sap.m.List Control in a application, however, I am struggling to find examples of how to implement this control in a JavaScript View. I am aware that the "Explored" app has code examples to implement the controls in XML views; However, I would like to know how to adapt those examples to HTML, JSON and JavaScript views. What an expert UI5 Developer does when he needs to adapt a control from a XML View to another type of view? Do we have any guidelines? Thanks in advance!
Regarding the guidelines you`ll find at least a quick introduction on js-views in the demokit documentation here.
I created a pretty simple example for the sap.m.List in javascript here although I am aware that it is not part of a view, but it should give you a first impression.
If you are looking for more js examples have a look here. For the older sap.ui.commons controls all samples are created with javascript.
What is to be understood by "Fluid powered TYPO3" (as stated by http://fedext.net/) and what are its benefits for the integration?
Are there other modern templating approaches for TYPO3 6.x that would be best practice to switch to now?
I don't understand the different systems that are around at the moment and I need some clarification.
The background of the question, what I am looking for:
Don't use Templavoila
Keep it simple, little coding overhead
That's why I still use markers!
Enable Custom content items in the backend like FCEs in TV
Foment "structured content" approach in TYPO3: predefined inputs and detailed rendering vs. "Anything goes" like in css_styled_content
And what about https://github.com/Ecodev/bootstrap_package ? Is it recommendable?
Although this question is fairly old by now (I didn't see it until now) and you probably already found out more about what Fluid Powered TYPO3 offers:
The features you ask for (TV-style FCEs, low coding overhead and especially the last one which is more regarding the process than the tool) are exactly what Fluid Powered TYPO3 is all about:
We provide simple ways to get page and content templates recognised by TYPO3 and made available to use by the site's content editors.
We use a common API approach (which is built on top of TYPO3's TCA/TCEforms) which you can use in both page and content templates to add custom fields (as an example: create a field to set the color of the site's header or configure a content element to have a blue background, and so on).
We use Fluid which is (as Michael already stated) a superb rendering engine.
But this is just a small part of the possibilities you have with the extensions (currently there are 20 - no, really, 20) which all provide different feature sets: there's the ViewHelper library VHS which you can use with any type of Fluid template, there's fluidpages, fluidcontent and fluidbackend which lets you place template files in a recognised path and made available to use without further hassle, there's view which lets you use overlay paths for plugin templateRootPaths (example: override only one template file from EXT:news without having to copy all template files from EXT:news). There's builder which can generate extensions, ViewHelper unit test classes, test your Fluid templates and more. There's tool which contains a range of Extbase Service-type classes that you can use in your own Extbase plugins. There's fluidwidget which is a great base for complex Fluid Widgets. You've got side utilities like *extbase_realurl* which can generate automatic realurl rules for any Extbase plugin. And there's schemaker which can let you create your own XSD schemas for your own ViewHelpers (or any version of for example fluid itself, or VHS, or flux etc.).
And there is more than this. Simply put, we offer you every tool you need to create every type of site, template or plugin. Our tools have one primary focus: efficiency.
It sounds like a huge mouthful but it isn't as complicated as it seems. Usually you will start off by using three or four of the extensions and their purpose is quite clear: Flux allows you to add the form fields which content editors use to configure content, pages and plugin instances; VHS provides a large number of multipurpose VieWHelpers to use whenever you need more than just those included with Fluid. And then one or both of fluidcontent and fluidpages which are -very- simple in that all they do is allow you to use template files as content elements or page templates.
There is quite a bit to get used to - this is true of any framework - but we spent a lot of effort on making the API the same across the line, which means anything you learn in one context (for example page templates) you can use in others (like content templates and backend modules).
If you want to save time and be consistent when creating content, pages and plugins, Fluid Powered TYPO3 (which is the umbrella name for all those twenty-something extensions) will do exactly that for you.
I can recommend taking a few minutes to read the new tour I published on fedext.net - the URL is http://fedext.net/tour/form-api.html - it primarily speaks to developers who've touched on Extbase and Fluid earlier, but even if you're used to "just" working with TYPO3 the main points should make sense.
And if you need more details than this you are welcome to find us on Github or on IRC (#typo3 on Freenet). We're always happy to help new users.
Cheers,
Claus aka. NamelessCoder
Fluid offers a much cleaner approach of dividing template logic from display logic and controller logic. Your result will be structured much better when using the possibilities fluid and the mentioned extensions like vhs provide (like layouts and partials).
The usage is actually very simple but can still be combined with the oldschool marker approach (you can do things like <f:cObject typoscriptObjectPath="lib.marks.MAIN-MENU"/>). If you need more flexibility in the backend like in TV, you (of course) have to code some things yourself.
The easiest way is to use an extension which is created by modelling it in the backend to fit your custom needs, but you can also adjust the rendering of pages and/or default content elements by using typoscript and the fields given (like pages.layout, header_layout, section_frame and so on).
So you always have the choice between detailed inputs (extbase extension objects) and using the TYPO3 default things like page properties and RTE config in combination with some typoscript magic (css_styled_content).
So as a conclusion I strongly recommend using fluid templates and additional extensions like vhs as they provide a lot of (additional) power and reusable templates while still let you use markers if you want to. Personally, I also prefer to enhance or limit the RTE in the backend in favor of writing too much special code for an FCE-like result.
BTW: There are very good autocomplete features by using the DTDs/XSDs from fedext.net in your IDE which made my template programming much faster (like 25%).
I am new to Zend Framework, but planning to create quite a complex project using it.
I was looking at the view options for Zend Framework. There is one with Zend_View and Zend_Layout and also template engines like Smarty can be integrated with it.
Now I would like to know, do they serve the same purpose? Like I can either use Zend_Layout or Smarty or is it better to use both?
I've worked on two large scale Zend projects. We don't use a separate layout engine, we just use the built in Zend_View.
Layering Smarty on top of Zend wouldn't serve much purpose (imo, would like to see some alternative experiences though)
I have seen lots of benefits of using smarty for nearly 10 years. First of all, smarty restricts template designers to use small set of functions which are related to view only. This will make easier to manage template files and will create a layer of security. Using PHP on view layer allows quick solutions with PHP and can create great mess. Smarty is compiled and there is nearly no performance loss. Syntax is more concise than PHP views. With Smarty 3 "template inheritance" features saved lots of time, which cannot be easily implemented with PHP classes.
I want to build an iPhone app that is really a wrapper around a wiki. Specifically, I have some static reference content that can be represented by a hyperlinked set of pages and want to build an app that will provide a nice interface over this content, including search, bookmarking, and annotating. I'm wondering what the best approach is for building something like this.
(I'm spent a fair bit of time googling for answers but pretty much every combination of search terms I can think of returns links to wikis, not links about putting a wiki into an app).
Are there libraries out there for handling wiki content (rendering, navigating links etc.)? I imagine I could just represent my content as a set of local HTML pages and point the web browser control at these but that doesn't seem right. Any ideas on how best to approach this in the iOS world?
Thanks in advance!
Try looking at TWedit, it is a wrapper for the excellent TiddlyWiki which is a single file WIKI built around JavaScript and HTML. TW is very powerful and well supported with many plugins available.