i want to implement my own localization tool over the typo3 database. Thus i implement a table with all localizations. But I have trouble to implement the functionality to render the label/localizations. Is there a hook, before normal rendering starts, so i can replace the fluid f:translation tag? Or can I extend the fluid f:translation helper?
I prefer the hook, but I am open to test something else.
best regards
Even though this document has seen its days, i find that it's still a very nice reference for hooks:
https://buzz.typo3.org/uploads/media/TYPO3_Frontend_Rendering_Process_v1.5.pdf
I suppose the one you're looking for is the determineId-PostProc hook.
Of course you can extend existing view helpers to your own namespace, not sure if you can overwrite existing core view helpers though.
Here's an article for extendind from an existing one (in German):
http://www.motions-media.de/2014/03/11/extbase-fluid-image-viewhelper-erweitern-fuer-lazyloading/
Related
I'm rewriting an app to ZF2 and I got stuck on problem of aggregating views from many modules on one page. What I want to achieve is to separate functionalities into modules, but still be able to display their views/actions (not sure how to name it) on one page. Let's say I'd layout a page with 4 containers and each of them would display some view from 4 different modules. Is it possible, if yes then how? Or maybe my though process is wrong here (I'm set on separating those functionalities though).
I've tried defining same or similar routes (eg. Module1: /boo/[:yah], Module2 /boo/[:whatever]). It didn't work because first module loaded was apparently served. And it looks like a mess too.
I've read a little about view helpers, but seemed to be aimed at a different purpose of providing common functionalities across many views. Whereas what I need if something like a layouting helper, view aggregation or something. I've worked with a home-made framework before that had this concept of site controllers, that would fire up different controllers actions. I can't find a way to emulate this in ZF2.
I'd appreciate any suggestions.
I've been applying forward plugin for this purpose as described in the blogpost suggested by Sam. It doesn't look elegant, but then I can't think of anything better myself.
I have a Rails 3.1 "blog" type app and my Post#index has become a sort of overview (or dashboard or sorts) into the whole system. The main content is pulled from the Post model but a sidebar contains info from an Event model, there are other snippets from a News model, etc…
Post#index is a busy action that has to populate many instance variable before /view/posts/index.html.haml gets a call to render and then the many layouts and partials go to work.
Being as some of these other areas are self-contained, so to speak, I'm wondering if there's a better "Rails way" to approach this? Perhaps I should be looking at encapsulating the Event sidebar (which is effectively Event#index) into some kind of entity that can be re-used perhaps in other views? And, if so, how?
What are the options?
You might checkout
http://cells.rubyforge.org/
I would look into widgetizing it. A framework that I looked into in the past was: http://apotomo.de/ This provides a nice clean way to widget"ize" as well as callback functionality (Ajax) for specific widgets.
I'm building an application that among other things allows users to upload documents. I have the basic create/view actions working just fine, but i'd like to reuse this action in other places.
I want to know if anyone has a pointer for how to do this. There doesn't seem to be a very good way of doing this.
Here are a few ways i've considered:
Try to do a chain(). This doesn't work since chaining does a GET, and to upload you need a POST.
Break out the main business logic into the Grails "service", and make two actions that use the same code.
Use a JS modal window. I've been thinking a modal that contains an iframe to an "unskinned" version of the document upload. The trick here is to get the window to close when the upload is done.
Thanks
--Matthias
I don't care for the extending controller method. In fact, I avoid inheritance when possible. I'd rather put the common code in a service class and reuse it that way.
You can use a base controller class, and place the common functionality there. Then extend the base controller and call the method from other action methods.
What is the best and cleanest way to implement A-B testing in asp.net mvc? That is, when we make new changes to an asp.net mvc web site, we want to test the new html/css/js with a certain subset of visitors (defined on cookie, login id, etc) and then analyze some metrics (page response time, number of pages visited, $$$ in sales, etc) afterwards to measure the level of success of the changes.
I am looking for a clean way to implement a way of choosing what view (html/css/js, etc...) to render using asp.net mvc.
Check out FairlyCertain (http://www.fairtutor.com/fairlycertain/) when you get a chance. It's a .NET A/B library that you can pretty much just drop into your project and start writing tests.
Unlike the Javascript libraries from Google and VisualWebsiteOptimizer, everything happens on the server so you don't suffer any performance, user experience or SEO issues. I've been using it in my stuff for a while now and it works quite well.
There is an A/B testing framework specifically for ASP.NET MVC. This is an open source software I wrote myself when, just like you, didn't find a free tool which works nicely with ASP.NET MVC and doesn't require much setup.
Google Content Experiments? It's a Javascript-based solution that doesn't require anything from your backend.
You include Google's Javascript on your page
The script randomly substitutes elements on your page as defined by your A/B test
Google's site shows you a nice breakdown of the results...
If you are using the spark view engine, you could probably do it with a variation of the theme filter (http://sparkviewengine.com/documentation/viewlocations#Extendingfilepatternswithdescriptorfilters). For each new visitor to the site, determine if you want them to see the existing or new version of the site and set a cookie. Wire up a descriptor filter that looks for the presence of the cookie and modify the view location to look in the folder containing the modified views. If an alternative view exists, the Spark engine will automatically render it in place of the "normal" view, otherwise it will render the normal view.
If you are using the normal WFVE, then the simplest way to manage this would be to define a folder under Views where your view alternatives live. When you want to provide an alternative view, you place it in a location that matches its position within the normal Views folder but rooted at the alternatives folder e.g. to provide an alternative to Views/Users/login.aspx place your new view at Views/Alternative/Users/login.aspx.
With a convention in place for locating your alternative views, you can extend the WebFormViewEngine and overload CreatePartialView / CreateView to inspect some aspect of the ControllerContext to determine whether to render the default or overloaded view and alter the path as appropriate e.g. changing .../Views/Users/login.aspx to .../Views/Alternative/Users/login.aspx.
I suggest you use Display Modes to achieve A/B testing.
But Display Modes just support simple problems by default.
If you already implement Display Modes in some other scenario. You can consider DisplayModeMatrix (just google it). It helps you use Display Modes more efficiency.
https://www.nuget.org/packages/DisplayModeMatrix/
Wth Display Modes you can simply delete/rename views after A/B testing to clean up your project.
I think there isn't a ready to use solution for this and you will have to improvise.
Try to override your current functionality in well defined points without breaking it. Explicitly draw a border where your regular code and A-B testing code lives.
Inversion of control principle might help a lot here too (i.e. - controller factory could provide derived controller instead of original one). For views&partialviews - you could change viewengine so it would try to look for 'MyPartialViewAB.ascx' instead of 'MyPartialView.ascx'.
And it might be a good idea to take a look what performance counters are (in case you haven't).
What is the purpose of the code behind view file in ASP.NET MVC besides setting of the generic parameter of ViewPage ?
Here's my list of reasons why code-behind can be useful taken from my own post. I'm sure there are many more.
Databinding legacy ASP.NET controls - if an alternative is not available or a temporary solution is needed.
View logic that requires recursion to create some kind of nested or hierarchical HTML.
View logic that uses temporary variables. I refuse to define local variables in my tag soup! I'd want them as properties on the view class at the very least.
Logic that is specific only to one view or model and does not belong to an HtmlHelper. As a side note I don't think an HtmlHelper should know about any 'Model' classes. Its fine if it knows about the classes defined inside a model (such as IEnumerable, but I dont think for instance you should ever have an HtmlHelper that takes a ProductModel.
HtmlHelper methods end up becoming visible from ALL your views when you type Html+dot and i really want to minimize this list as much as possible.
What if I want to write code that uses HtmlGenericControl and other classes in that namespace to generate my HTML in an object oriented way (or I have existing code that does that that I want to port).
What if I'm planning on using a different view engine in future. I might want to keep some of the logic aside from the tag soup to make it easier to reuse later.
What if I want to be able to rename my Model classes and have it automatically refactor my view without having to go to the view.aspx and change the class name.
What if I'm coordinating with an HTML designer who I don't trust to not mess up the 'tag soup' and want to write anythin beyond very basic looping in the .aspx.cs file.
If you want to sort the data based upon the view's default sort option. I really dont think the controller should be sorting data for you if you have multiple sorting options accessible only from the view.
You actually want to debug the view logic in code that actuallky looks like .cs and not HTML.
You want to write code that may be factored out later and reused elsewhere - you're just not sure yet.
You want to prototype what may become a new HtmlHelper but you haven't yet decided whether its generic enough or not to warrant creating an HtmlHelper. (basically same as previous point)
You want to create a helper method to render a partial view, but need to create a model for it by plucking data out of the main page's view and creating a model for the partial control which is based on the current loop iteration.
You believe that programming complex logic IN A SINGLE FUNCTION is an out of date and unmaintainable practice.
You did it before RC1 and didn't run into any problems !!
Yes! Some views should not need codebehind at all.
Yes! It sucks to get a stupid .designer file created in addition to .cs file.
Yes! Its kind of annoying to get those little + signs next to each view.
BUT - It's really not that hard to NOT put data access logic in the code-behind.
They are most certainly NOT evil.
Ultimately, the question you ask yourself is this:
Does this code A) Process, store, retrieve, perform operations on or analyze the data, or B) Help to display the data?
If the answer is A, it belongs in your controller. If the answer is B, then it belongs in the view.
If B, it ultimately becomes a question of style. If you have some rather long conditional operations for trying to figure out if you display something to the user, then you might hide those conditional operations in the code behind in a Property. Otherwise, it seems like most people drop the code in-line to the front end using the <% %> and <%= %> tags.
Originally, I put all my display logic inside the <% %> tags. But recently I've taken to putting anything messy (such as a lengthy conditional) in my code behind to keep my XHML clean. The trick here is discipline - it's all too tempting to start writing business logic in the code behind, which is exactly what you should not be doing in MVC.
If you're trying to move from traditional ASP.NET to ASP.NET MVC, you might aviod the code behinds until you have a feel for the practices (though it still doesn't stop you from putting business logic inside the <% %>.
There isn't a purpose. Just don't use it except for setting the model
ViewPage<Model>
See this blogpost for more info.
At this Blogpost is a working example of removing the code behind.
The only problem I'm stuck with is that it is not able to set namespaces on the class.
The codebehind provides some of the strong typing as well as the intellisense support that you get in the view. If you don't care about any of these two features, you can remove it.
For example, I typically use the NVelocity ViewEngine because it's clean and pretty straight forward.
This is a great question. Doesn't MVC exist in the ASP.NET environment, without using the specific MVC pattern.
View = aspx
Controller = aspx.cs (codebehind)
Model = POCO (Plain Old C#/VB/.NET objects)
I'm wondering why the added functionality of MVC framework is helpful. I worked significantly with Java nd MVC and Java Struts several years ago (2001), and found the concepts in MVC to be a solution for the Internet Application organization and development problems at that time, but then found that the codebehind simplified the controller concept and was quicker to develop and communicate to others. I am sure others disagree with me, and I am open to other ideas. The biggest value I see to MVC is the front controller pattern for Internet development, single entry source for Internet Application. But, on the other hand, that pattern is fairly simple to implement with current ASP.NET technologies. I have heard others say that Unit Testing is the reasoning. I can understand that also, we used JUnit with our MVC framework in 2001; but I have not been convinced that it simplifies testing to use te MVC framework.
Thanks for reading!