Are there any good thing, best practice or profit we have after using the HTML helper in an ASP.NET MVC project?
When I am trying to use them I found that I lose the speed I have with HTML and many difficulties I have whenever I use an HTML helper.
Other [non-techie] persons can't understand what I write using Helper if I want to show them or they want to do something they need to spent more time on, even if they have working knowledge of HTML.
If I use an HTML helper I lose the speed. When I use HTML I just type and of course I am not aware of it. But using helper, it is hard to understand.
What thing do we get when I use HTML helper? I think it is nothing I get because I lose the speeed. Others can't understand what I do using helper and can't customize the code if they want.
Why do we use HTML helpers?
You use HTML helpers to encapsulate some small HTML fragments which are repeated all over your pages. And to avoid writing those HTML snippets all over again you use helpers.
They are very useful, especially when dealing with things like URLs because instead of hardcoding your links helpers take advantage of routing the definition on your server and by simply changing those routes the whole site URLs' change without ever touching any single HTML page.
Another scenario where HTML helpers are useful is for generating form input fields. In this case they automatically could handle values when posting back and show associated validation messages. Can you imagine the spaghetti code you would have to write in your views if there weren't HTML helpers?
The biggest advantage I find is with the editor and display templates.
If your editor for a field is more than just a simple input box, you can put that into a template and replace the several tags with a call to
<%:Html.EditorFor(m=>m.Property)%>
This means that your page is a lot easier to edit as you aren't wading through a lot of fluff HTML to find what you want.
Related
It is mandatory to use a Zend Form everytime I need one? Can I do it with a simple html form in my phtml?
Are there dangers or trouble using the html one?
You can still use pure html forms wherever you want.
Zend_Forms try to help to easily implement the best pratices particularly validating, filtering and escaping user input. If you use pure HTML, you may forget these best pratices.
Up to now, I used to use template auto-parser. I like the fact I can modify any element of the template using typoscript, without altering the initial HTML file. I also like the fact that I can render the html template directly in a web browser, filling it with dummy elements to see examples of menus and content elements. Finally, with the new backend templates, i now can place content elements anywhere on a grid, in a way that mimics the real aspect of the website.
I know there is also TemplaVoila. I never took the time to learn it. My feeling is that it is less compatible with some extensions, but maybe I am wrong.
Now, there is fluid, that will be used in the next version of Typo3. While it is clear that it is better using it that using template markers, I don't really understand why I should be better using Fluid than using template auto-parser or TemplaVoila. What I dislike is the fact it requires to modify the html template with special tags, meaning that either the web designer has to know Fluid, or the Typo3 integrator has to modify templates from the designer each time a modification is performed.
My question is: should I migrate form template auto-parser to Fluid for my website template? What are the benefits of using Fluid? Why should it be better? What template system should I use with Typo3?
As long as TypoScript does not support objects, the benefits of FLUIDTEMPLATE over template auto-parser are only a few. So there is no need to migrate.
But IMHO there are some arguments to switch to fluid:
more and more extensions will use fluid, so it will help you to learn fluid
you can use an ide with code-completion for fluid (it is just XML!)
fluid is really powerfull, you can have f.e. if statements which checks for empty content
some day TypoScript will support objects as well
But for extension developement, it is totally different. In an Extension, i would allways prefere using FLUID. You do not have to deal with template things inside your extension anymore. Just pass the data to fluid and things which concern the view will be done in your template.
Whever you choose, it should be something based on Fluid - this will allow you to be extremely versatile and it makes the implementation less important than the template, which is quite good.
I myself am the creator of the "Fluid Powered TYPO3" framework (formerly known as FED) and would of course recommend that you take a look at what this framework can do for you - it's capable of great things, not the least of which is saving you a lot of time while at the same time allowing you to create even more consistent templating for pages and content - and even backend modules.
And we're always happy to help new users. We are currently in the process of improving our documentation, but you can already find many fully up-to-date guides on our Github page - https://github.com/FluidTYPO3 - the repository called "documentation" is the place we will store all the documentation.
You may want to have a look at http://fedext.net http://fluidtypo3.org - especially the "Tour of features" which tries to explain the point of Fluid Powered TYPO3 in as few words as possible. After that, the examples from the documentation will give you a much clearer picture of what Fluid Powered TYPO3 can do for you.
We focus on efficiency always - we've tried to do all the heavy lifting so that you really can just sit down and begin creating page templates. We took a lot of inspiration from TemplaVoila but there is no more re-mapping of content and things like this: when you change your templates, that change is immediately reflected, which makes it very nice to work with in iterations and do things like continuous delivery and -integration.
Hopefully this helps!
Cheers,
Claus aka. NamelessCoder
You could also argue, that adding special tags like
<f:section name="typo-content">
<div id="content">This is where the designer intended content to go</<div>
</f:section>
Could assist your designer while doing a redesign to know where you "mapped" your content elements to. This is neither the case with autoparser nor with TemplaVoila. So if the designer moves stuff around you probably get your templates back and they still work without any modifications.
I could not find a wicket tag like wicket:include? Can anyone suggest me anything? I want to include/inject raw source into html files? If there is no such utility, any suggestions to develop it?
update
i am looking for sth like jsp:include. this inclusion is expected to be handled on the server side.
To do this, you'll need to implement your own IComponentResolver.
This blog article shows an example somewhat resembling what you're after.
Is it raw markup that you want to include, or Wicket content?
If it's raw markup, even a simple Label can do that for you. If you call setEscapeModelStrings( false), the string value of the model will be copied straight in the markup. (Watch out for potential XSS attacks though.)
"Including" Wicket markup is done via Panels (or occasionally Fragments)
Update: If you add more detail about the actual problem you need to solve, there's a good chance that we can find a more "wickety" solution, after all, JSP and Wicket are two different worlds and the mindset of one doesn't work very well in the other.
I am almost at the end of my rope trying to style my Zend form using decorators. Previously to avoid these issues I would create a form script extending zend_form, add whatever validators, labels, etc I needed then retrieved the element from my view script using $form->getElement('my_form_element');
that way I could wrap whatever css tags I wanted around the element. I thought I should learn how to use the built in decorators, but I'm starting to feel like it's a waste of my time. My old way seems easier, is there some reason I am not seeing that makes using custom decorators better?
In general decorators are used to dynamically add functionality without having to touch the code's core functionality and for a better re-usage of code. In Zend_Form however, I think that the decorator system (as well as Zend_Form in general) is unintuitive and heavily over-engineered and so it does exactly the opposite of what it should do: Help the developer to create better and more intuitive code faster.
In my opinion the usage of Zend_Form_Decorator makes only sense in the case where you have some extended logic that you plan to reuse throughout your project on multiple and different types of elements.
Let me give you two examples:
You want to add a tooltip icon next to an arbitrary form element with a nice icon and a fancy JavaScript hover box.
An element should be validated directly upon entering data by posting an AJAX request and adding either a green check mark on success or a red cross icon on failure next to the element.
With the decorator you can now separate the logic of the added functionality from that of the underlying element and so you can use the same code to add the tooltip and/or the live validation feature to a textbox element as well as any other element simply by adding all the decorators you want to the element.
There is also a great article from Matthew Weier O'Phinney, the lead developer of Zend Framwork, that gives some background insight on the motivations for using decorators along with a lot of examples: Decorators with Zend_Form
Decorators can come in handy if you have a specific repeatable markup for your forms, for example if you want to use Bootstrap. Other than that, especially if you have a good html/css person, I would avoid them.
I have made a simple blog using Node/Express/Mongo/Jade (and/or HAML.js). I used (and slightly updated) the blog app from this tutorial, which itself an update of one from howtonode.org
I can render attributes such as links, etc., with the template engine just fine, but when I pass data from the db, none of the html renders. I get plain text print-outs of the HTML. I figure I need some other node packages/modules to render the 'dynamic' content, but I don't know where to start.
In jade, when you're passing content you DON'T want to be escaped, be sure you pass it along as != instead of =
BE EXTREMELY CAREFUL THOUGH! If you don't manually parse out the bad stuff, you could make your website extremely vulnerable.
You can read some more jade documentation here