I'm using snippets to break up long templates into more manageable chunks, is this bad practice and should I only use snippets for reusable code?
Thanks
Lee
It depends of what you are doing in your templates.
It is indeed generally a good practice to reuse part of templates in smaller chunks, but it's recommended to avoid the usage of embeds because of underlying performance issues.
Snippet are cool as soon as you don't have to pass variables to your sub-templates.
Maybe a good approach for you if your templates are not already totally coded is to use the 'template partial' technique. See the following tutorials here under.
Template Partials using Stash
Homegrown plugin to create template “partials” for ExpressionEngine
You should look at using an add-on, I use either Low Variables or Republic Variables (free), where you can store snippets and parse them early or late. They can also be saved as files which is handy.
You can find them on http://devot-ee.com
Related
I am very eager to learn in the area of web-development and lately I started learning server-side programming after doing front-end web-development first.
Now it appeared to me that there are some templating languages such as jade/pug. However I cannot seem to fully understand the concept/purpose of these languages.
Do you first create your front-end part using html5 and css and then
convert this html to pug in order to use it for server-side
programming?
if so, why not just use html?
Or do you actually create your webpages using pug from scratch?
I do understand that a lot of information can be found with a quick google search. Therefore I want to emphasize that I actually did a lot of searching already. However, I cannot seem to fully grasp the concept or maybe I don't ask the right questions.
Therefore, I would really appreciate it if someone could explain what the exact role of these templating languages is in web development so that I understand the bigger picture.
I am using pug for three main reasons:
less to write (CSS selector like syntax, no closing tags)
better readability because you are basically writing the DOM instead of tags
the "extends" functionality to avoid duplicate code
Other (obvious) reasons are the possibility to use variables, loops, if-statements or even function calls to format or transform data in any possible way.
I usually create a layout.pug file containing everything that is contained in every page plus a block main and other views that extends layout. Depending on the project I also use a block head and block script to allow specific pages to inject additional stylesheets or scripts.
I got used to only writing pug code combined with stylus which concept is quite similar, so having to write plain HTML or CSS from time to time even got annoying.
Pug is also great in combination with bootstrap and/or Angular so I see no reason not to use it.
I am planning to build a web dashboard where I can analyze the financial records from a company through graphics, tables, ...
I already have the software, so the dashboard will only read the data, and not manipulate it.
It will be something like this, but simpler. Containing reports, graphics, options to select dates, intervals, etc.
But I am thinking, is it viable to use Clojure? And jQuery, CSS, HTML also.
Currently I work with the Luminus Web Framework for Clojure, but I am wondering if it is worth to do this in Clojure or if there are other languages that are better to do it.
Of course I am familiar with the language already, so it is a pro. But I am also open to suggestions.
It is not that hard at all! In fact, there exist great libraries which solve all the challenges involved in building a dashboard - scheduling, caching, transferring data to the client, visualization(and auto reloading).
We are working on a framework for building realtime Clojure dashboard. Have a look at https://github.com/multunus/dashboard-clj. We have used the following libraries:
Immutant's scheduler for scheduling
Core.async to simplify data flow on the backend
Sente for websocket communication
re-frame for client side state and view management
Stuart Sierra's component library for managing stateful components
In order to create beautiful visualizations you may take a look at d3 or highcharts. CLJSJS and Reagent cookbook will gives a good overview of how to use these js libraries(and many many more).
Clojure is an absolutely fantastic tool for building a web dashboard. The other answers here do a pretty good job of laying out the landscape as far as basic web technologies. On this side of things, I'll simply add I'm a big Reagent / Re-frame fan, and would go that route for React wrapper over Om.
As far as data visualizations, you may be interested in checking out Vega-Lite & Vega, which you can use from Clojure or ClojureScript (Reagent) by using a simple but flexible dataviz library I wrote called Oz:
https://github.com/metasoarous/oz
Vega-Lite & Vega are designed based on the ideas of the Grammar of Graphics, which inspired R's popular ggplot2 library. The core idea is that data visualizations should be built according to declarative descriptions of how properties of the data map to aesthetics of the visualization. Vega-Lite & Vega however take things one step further in providing a grammar of interaction, which allows for the construction of interactive data visualizations and sophisticated explorer views. Moreover, it ups the ante on the declarative nature of the GG in that Vega-Lite and Vega specifications are described as pure data (JSON), making it very in line with the data-driven philosophy of the Clojure world, and paving the way for seamless interoperability with other languages and sharing features.
Vega-Lite is more or less the higher lever, day-to-day data science tool, focusing on providing high leverage and automation based on very spartan specifications. It compiles to Vega, which is a somewhat lower level and more powerful, but less automated version of Vega-Lite. Usually starting out with Vega-Lite, and switching to Vega only as needed is sufficient.
For more on Vega & Vega-Lite see: https://vega.github.io.
I don't see any reasons why it wouldn't be viable to build a web dashboard in Clojurescript.
I suggest that you look into a library call reagent, which provides a minimalistic interface between react and clojurescript, so theoretically everything you can do with react should be possible in clojurescript/reagent (with the added benefit that it will be faster than React). You probably might be interested in reframe which is a framework for building single page applications.
React has been proven as a robust tool to build powerful UI.
You can do everything you can do in JavaScript using ClojureScript (just as you can do everything you do in Java using Clojure). So as others have commented, I would definitely recommend ClojureScript, especially since you know Clojure already. You may find out that you do not need jQuery etc.
The common choice to generate html is to use React.js via a wrapper library like:
reagent
Om
Both can generate HTML.
Reagent (and maybe re-frame) are the easiest ones to get started. Especially since there are components libraries like soda-ash, and a hiccup-like syntax.
Om (by the creator of ClojureScript), and maybe untangled are also a good choice, especially if you need to manage complex data. You can get a hiccup-like syntax via sablono.
Dashboards have been built using it (see the circleCI dashboard as a real-life dashboard example). This is the one I use personally.
Hoplon is also an interesting choice, as you mentioned.
Also have a look at cljsjs for pre-packaged js libraries.
As for the CSS, this is an orthogonal concern but yes of course you can use it (or even less and sass, there are Clojure wrappers for it). You can even generate CSS from Clojure code with garden,
You can find an example project using boot (by the same authors as hoplon), sass, reagent called saapas, but there are many more in the wild.
As you see there are many viable options in ClojureScript to build a dashboard. I am myself building one and settled on Om.next, partly because I was using React.js before.
From a performance/maintenance point of view, is it better to write my custom modules with netsuite all as one big JS, or multiple segmented script files.
If you compare it with a server side javascript language, say - Node.js the most popular, every module is written into separate file.
I generally take the approach of Object oriented javascript and put each class in a separate file which helps to organise the code.
One of the approach you can take is in development keep separate files and finally merge all files using js minifier tool like Google closure compiler when you deploy your code for production usage which can give you best of both worlds, if you are really bothered about every nano/mini seconds of performance.
If you see SuiteScript 2.0 architecture, it encourages module architecture which is easier to manage as load only those modules that you need, and it is easier to maintain multiple code files i.e. one per module considering future enhancements, bug fixes and code reuse.
Performance can never be judge by the line count of your module. We generally maintain modules for maintaining the readability and simplicity of the code. It is a good practice to put all generic functionalities in to an Utility script and use it as a library across all the modules. Again it depends on your code logic and programming style. So if you want to create multiple segments of your js file for more readability I dont think its a bad idea.
I've heard mixed things about this. I know it's easy when you're stuck to simply enable PHP in the template and hack your way around a problem. However, it almost always introduces potential security issues, and makes a mess of your template to boot.
In most cases where PHP is used, it would be cleaner to write a simple plugin in PHP to achieve what you need.
My question is this: Is it ever acceptable to use PHP inside ExpressionEngine templates? Or is this considered bad practice? If you were a developer who inherited a site I coded, would you cringe if you saw PHP inside templates?
This could just as easily be a question on the merits of eval() and whether it should ever be used. Most of the answers to questions along those lines are equally applicable here.
My view is that enabling PHP in templates is always a Bad Idea. At best, it's not a terrible idea, but there's always a better option. A custom addon will invariably be a better approach, even with seemingly harmless code snippets. I think it's also most likely to be used by those least qualified to use it. Personally, when I started building sites with EE my PHP skills ranged somewhere between 'totally inept' and 'knows enough to be dangerous'. At that time, if I came across a limitation in EE's code I'd often implement a solution via some inline PHP, partly because the idea of developing a custom addon seemed too daunting and partly because clicking a little 'enable PHP' radio button was so simple. Years later, whenever I need to update one of these sites, I definitely do cringe. Here are some of the side effects of PHP in templates:
Potentially introducing serious security vulnerabilities.
Increasing load times, potentially by a lot.
Debugging code becomes harder (good luck figuring out which file/line number has that error).
With tools like Pkg.io you can have the groundwork for an addon in place in 30 seconds. It requires a tiny amount of extra effort, but the gains are well worth it.
Let's imagine I'm answering this question as part of the 80% of people building websites with ExpressionEngine who may consider themselves as designers and or people who have little to no PHP experience:
Is it ever acceptable to use PHP inside ExpressionEngine templates?
No it's not acceptable, please don't do it!
Or is this considered bad practice?
Yup, pretty much.
If you were a developer who inherited a site I coded, would you cringe
if you saw PHP inside templates?
Definitely would cringe and maybe even curse a little.
Okay, now let's imagine I'm answering as part of the 20% who would consider themselves as an EE developer and or who have most experience programming over say designer all day:
Is it ever acceptable to use PHP inside ExpressionEngine templates?
Once in a while it's acceptable. For example you might find a need to turn on PHP for this Stash setup. It really depends on the complexity of what you are trying to achieve. Most things should go into an add-on whenever possible and being "lazy" doesn't count as a time when PHP is acceptable in templates.
Or is this considered bad practice?
ExpressionEngine and Codeigniter for that matter provide a great base to build add-ons and best practices include proper separation when ever possible. This includes separation from PHP and Templates; more often than not.
If it can go into an add-on it should as mentioned before. With that said, there isn't really anything limiting you from using PHP in templates except knowing that this may have security implications, cause future headaches for clients and other devs/designers etc.
If you were a developer who inherited a site I coded, would you cringe
if you saw PHP inside templates?
Definitely wouldn't cringed (unless your PHP was a disaster right from the start) though, would probably question why such simple and even complex code wasn't where it belonged; in an add-on.
Note: I pulled the percents out of thin air though, they quite possibly could be close to reality.
Also note: I realize the use of designer/developer in my answer could be seen as stereotyping though, wasn't quite sure how to avoid it. Hope no one takes offense.
I would consider using something like the phpstringfun add-on. This splits the different, but you're still working in EE tags.
I wouldn't sweat using small amounts of well-documented PHP in templates, but keep it as simple and abstracted as you can.
I'm using an external java library for which I only have the javadocs and do not have the source code. I'd like to generate a UML diagram from the existing javadocs so that I can visualize the class hierarchy using something like Graphviz. Is that possible? Note that what I'm looking for is a graphical version of overview-tree.html.
Please let me know if you have any ideas and/or suggestions.
Thanks,
Shirley
I don't believe that there is such a tool. Most of the reverse engineer tools depend on the actual code. The javadoc information isn't guaranteed to match the code as a 1:1 for the structure, thus making it unreliable.
I'm not familiar with any off-the-shelf solution for this purpose. Most commonly folks have the source code that generated the JavaDoc.
That being said, the overview-tree.html traditionally has a fairly straightforward HTML format.
It should not be difficult to write a script that would read the file as text or as a DOM, reconstruct the hierarchy of UL and LI tags, and use that to build an input file for graphviz. I've done similar stuff in the past with other forms of data.
It's just a matter of time and proficiency with the scripting language or appropriate tools.
The one problem of this approach is that you would only get the hierarchy of classes. You would have to make it somewhat smarter if you wanted to get the "implements XYZ" and create multiple hierarchies. Even if you could get that data, you would have to manipulate GraphViz's levels to get it to provide an appropriate layout once you have this multiple inheritance structure.
Of course, adding the details of the members would turn this into a whole new problem since you will have to access other HTML files.