For all the things I love about Grails I do have one small issue and this isn't really even a Grails specific problem. GSP changes require redeployments of the entire web application. I'm not talking about adding new dynamic data or major changes. These generally requires server side changes as well anyway.
But I'm talking about smaller changes like flipping the position of a couple of elements or modifying some simple static text on the page. So my question is, what are some patterns used or plugins, etc that allow minor changes to GSP's without redeploying the entire application? How can I make Grails template/GSP's more like templates and less requiring compiling?
I'm also possibly looking for something more designer friendly.
grails.gsp.view.dir, I think.
A trick to remember: add trailing slash and remember that grails-app/views will be added to it.
There is a Grails Plugin for using FreeMarker templates as views (I have not used this plugin myself). It is not listed as SpringSource supported, but I think the author is one the core grails devs and the plugin is based on a relatively new version of FreeMarker.
Related
I'm developing an OpenCart shop using OC 2.1 and I'm struggling to understand what is the best solution for creating custom changes on controller level.
Here's a simplified example to show you what I'm wondering about:
I'd like to modify my header. The graphic design I'm implementing uses different writing for My account link depending on if the user is already logged in or not. This is of course a very simple thing to change, so here are my ideas:
I could just edit my new template's header.tpl file to use:
<?php echo $logged ? $text_account_signed : $text_account; ?>
That requires a change in a language file and that file is outside of the template folder. I'll leave the language issue out for this example to make it less complicated.
But to create a solution that is more MVC I should make that change in the catalog/controller/header.php file, shouldn't I? Unfortunately that file is outside of the template folder so in case of an update, the change will be lost or would require fixing by hand.
I could however create an extension with an extension.ocmod.xml file that would make a change in the controller header.php file and it would be safer (not sure if 100% sage though) for future updates. But the amount of extensions and/or the complexity of creating them would greatly impact my project time, I suppose. And that makes me tempted to just edit the source code of OpenCart and make my future self worry about it later. But I care about this guy and I'm sure he'd hate me for that at some point.
So, my real question is: Is there a way of creating OpenCart modifications on controller level that would not break future updates?
Regarding modifying existing Controller, Models, Languages yes you either need to use vQmod or OCMOD and for template yes you can create your own template according to need. there is no other option.
If you are using vQmod or OCMOD then you don't have to worry about updates because there is less chances of issue (issue may occur only in major updates).
For vQmod there are other easy tools like vQgen and vQmanager available
For Opencart Overall general info
I have a lot of experience with AngularJS and I'm also playing around with Web Components and Polymer for a long time now.
What I really love about the these libraries and technologies, is the fact that they let me build my own components.
AngularJS gives me something called "Directives" and Web Components consists of a set of specs where one is called "Custom Elements", which pretty much does how it's called.
So with these I can do something like:
<my-element></my-element>
This is where the web goes, this is what everybody loves about HTML. Declarative tags that are easy to read and encapsulate functionality and behaviour. Also very nice: once Web Components are fully supported in the browsers, I could for example very easily remove my directive and rely on a web component, that looks and works the same without changing any code.
I know, that EmberJS has something called "Ember Components" which lets you basically build your own kind of components too. However, using them in HTML looks something like this:
{{#my-component}}
{{/my-component}}
Is it possible in EmberJS to also use components declaratively as tags?
I actually hate that about html. I hate the structure etc, but that's just my opinion :)
No, there isn't, your component should be declared in a template using the handlebars syntax, and compiled to js. (you can dynamically create views/components, but that's far from declarative tags).
You'll be able to do that when Glimmer 2 ships with Ember. It was supposed to be in with Ember 2.x, but for some reason its still pending. With that you can use angle brackets to define components.
<my-element></my-element>
How can multiple developers work on the same website (CSS, JavaScript, ASP.NET).
We use SVN as source control, but the problem is more in regards of testing and general workflow.
I know we could do unit tests and we have for our API, but I don't see how we can do unit testing for our frontend?
We get a lot of problems in the frontend like:
Developer 1 changes CSS and it messes up CSS for developer 2.
Developer 1 changes JavaScript and components developer 2 made stops working.
Developer 1 removed an ID or a CSS class in C# (code behind) and CSS styling is lost or JavaScript stops working.
It's basically things of that nature.
What we do now is manually test everything in all major browsers and we spend too much time on that.
Any good suggestions on how we can improve our way of working? Keep in mind that it's a website and we are struggling with problems related to that.
This is a management issue rather than a workflow issue.
You need to be proactive at managing the situation and be tough.
You have a source control system in place, what you need to do is:-
Enforce day end (or more frequent if preferred) check ins.
Rollback work if it doesn't work. You have to be tough on this point to ensure the developers understand that you mean it.
You need to actively communicate the above to your team to make sure they understand the new work procedures.
It'd only take a few weeks for it to sink in, after that you can relax the controls.
Introduce releases/iterations/milestones; and publish them only from the repo.
Can you not possibly break the site areas up into segments and assign developer responsibilities to each, even if it means sandboxing the "base" code of the site (framework / main CSS / main JavaScript) and assigning a specific responsibility to it? You can then task developers to keep their CSS / JavaScript separate from the main files and merge them before testing and release.
We've had similar problems where I work and this approach seemed to sort it out for the most part. For each segment we built we created a new folder in each of the respective projects (DAL / BL / Presentation), based on the functionalities / modules / segments, each with their own site content (JavaScript / CSS), but still making sure that some generic styling and JavaScript being available to all developers.
An official Agile project management methodology (like Scrum) has huge benefits in an environment like this, as you get to discuss these issues on a daily basis and, if over-arching requirements for new CSS and JavaScript are identified by all developers, it can be integrated into the site's base content.
I am going to pick up a task that no one has ever attempted to try at my workplace. It is a CF app first written using CF 2.0 (Yes, 2.0!) 10 yrs ago with > 10 cfscheduler tasks.. We explored the idea of rewriting the app, but 10 yrs of work simply can't be rewrote in 2-3 months.
What steps shall one take to modernize the app into a maintainable, extendable state? The one that I keep hearing is "write tests", but how can I write tests when it wasn't even in MVC?
Any advice would be appreciated, thanks!
p.s. I should thank Allaire, Macromedia and Adobe for keeping CF so freaking backward compatible all the way back to 2.0!
btw, what's the most modern, maintainable state for a CF app without MVC framework? or should my end goal be ultimately refactoring it into a MVC app?? I can't image how many links I will break if I do... seems impossible... thought?
update: found 2 related Q's...
https://softwareengineering.stackexchange.com/questions/6395/how-do-you-dive-into-large-code-bases
https://softwareengineering.stackexchange.com/questions/29788/how-do-you-dive-into-a-big-ball-of-mud
I am not sure if you need to move the whole site to a MVC application. Recently I did helped with an site that was not MVC, that still had a library with the Models, Services and Assemblers in a clean and organized manor. It worked great, and we didn't need to do anything more than what was necessary.
That being said, my first step would be to organize the spaghetti code into their different purposes. It may be hard to properly create the models, but at the very least you could break out the services like functions from the pages. With that done, it should be a lot cleaner already.
Then, I would try to take the repeated code and put them into custom tags. It will make the code more reusable, and easier to read.
Good Luck!
Consider, whether a full fledged framework is really necessary. In its most basic form a framework is merely highly organized code. So if procedural, that is well organized, works leave it.
Keep in mind something like FW/1 as migration path can be better than say Coldbox if you don't need all the other stuff.
Lastly, consider this I was able to migrate a 4.5 almost 70% of the way to Coldbox (very simple and really more about directory and file organization versus IOC, plugins, modules, etc...) just using a few extra lines per file plus onMissingMethod functions.
Good Luck.
I had to deal with a similar situation for about two years at my last job, however, it wasn't quite as old as yours. I think I was dealing with code from 4.0 on. There's no silver bullet here, and you'll need to be careful that you don't get too caught up in re-factoring the code and costing your company tons of money in the process. If the app works as it is rewriting it would be a pretty big wast of money.
What I did was update small chunks at a time, I wouldn't even refactor whole templates at a time, just small portions of one at a time. If I saw a particular ugly loop, or nested if statements I'd try to clean it up the best I could. If the app can be broken down into smaller modules or areas of functionality and you have the extra time you can try to clean up the code a module at a time.
A good practice I heard from the Hearding Code podcast is create a testing harness template that would use a particular cfm page that has a known output that you can re-run to make sure that it still has the same output once you've done refactoring. Its not nearly as granular as a unit test, but its something and something is almost always better than nothing, right?
I suspect that the reason this app hasn't been touched for years is because for the most part it works. So the old adage "if it ain't broken don't fix it" probably applies; However, code can always be improved :)
The first thing I'd do is switch to Application.cfc and add some good error logging. That way you may find out about things that need to be fixed, and also if you do make changes you're know if they break anything else.
The next thing I'd do is before you change any code is use selenium to create some tests - it can be used as a FireFox plugin and will record what you do. It's really good for testing legacy apps without much work on your part.
Chances are that you won't have much if any protection from SQL injection attacks so you will want to add cfqueryparam to everything!!
After that I'd be looking for duplicated code - eliminating duplicate code is going to make maintenance easier.
Good luck!
Funnily enough, I'm currently involved in converting an old CF app into an MVC3 application.
Now this isn't CF2, it was updated as recently as a year ago so all of this may not apply at all to your scenario, apologies if this is the case.
The main thing I had to do consolidate the mixed up CFQuerys and their calls into logical units of code that I could then start porting in functionality either to C# or JavaScript.
Thankfully this was a very simple application, the majority of the logic was called on a database using the DWR Ajax library; that which wasn't was mostly consolidated in a functions.cfm file.
Obviously a lot of that behavior doesn't need to be replicated as packaging up the separate components of logic (such as they were) in the CF app did map quite neatly to the various Partial Views and Editor Templates that I envisaged in the MVC application.
After that, it was simply a case of, page by page, finding out which logic was called when, what it relied upon that then finally creating a series of UML class and sequence diagrams.
Honestly though, I think I gained the most ground when I simply hit File-New Project and started trying to replicate the behavior of the app from the top of index.cfm.
I would break logical parts of the app into CFC's
Pick a single view, look at the logic within. Move that out to a CFC and invoke it.
Keep doing that you will have something much easier to work with that can be plugged into an MVC later. Its almost no work to do this, just copy and paste sections of code and call them.
You can consider using object factory to layer your application. We have similar situation at work and we started refactoring by putting Lightwire DI framework.
First we migrated all the sql statement into gateways, then we started using services and take a lot of code out of the templates to the services.
The work is not finished yet but the application is looking better already.
For large, really complex applications I'd prefer ColdBox for a re-factor project. However, I just saw a presentation at the D2W Conference on F/W 1 (Framework One), a VERY simple ColdFusion MVC framework. Check out code from the presentation here.
It's 1 (one) CFC file and a set of conventions for organizing your code. I highly recommend evaluating it for your project.
I am new to Joomla, started learning it just a day ago and didn't manage to find an answer to my question in the docs (which suck real bad compared to Drupal).
So what I want to do is override the whole module in a template. The documentation only suggests I can override the markup of a module by placing corresponding files in the html folder, but I have to make some corrections to the actual logic. Is copying the module, changing and then installing it as a separate entity the only way to go? I mean it makes sense that "template" folder is for "views" but with the kind of application I have to develop it is gonna be annoying...
Yeah, you can only override views.
If you want to override logic, you have 2 options:
Change the actual logic in-place, which leads to problems on updating etc
Duplicate the module and change the logic, as you suggested
One other way to consider is to replicate or fix the logic in the template. While this is not a very slick way of doing it, it is faster, especially than duplicating a whole component.
Note that you can also add your own libraries to the Joomla libraries folder to centralize your own code.
Further, if you manage your code with (for example) svn, you should not have any problems on upgrades with creating new views that may include their own logic.