well I'm a php programmer who for a period create some php application by using codeigniter framework. Now I would pass to the next level using a framework more powerful and my choose is gone to symfony framework. I read good things about it and looking for some infos about it, it seems me a good next level. I saw that it uses a templates engine names Twig and since I come from codeigntiter I fell a little uncomfortable.now I would know which are the advantages in using twigs?is it really of help using it in web application?
In my short, subjective opinion, templating engines typically result in cleaner views, and in some engines' cases (some more than others), better enforcement of separation of concerns.
As far as discussions & articles go, there are many if you search for them. Here are a few references though:
What are the real advantages of templating engines over just using PHP?
PHP vs template engine
(older, and also could be biased towards Twig since it was written by Fabien)
http://fabien.potencier.org/article/34/templating-engines-in-php
Twig's website even gives you an overview of why it can be helpful:
http://twig.sensiolabs.org/
One thing to keep in mind regarding Symfony is that you are not locked in to using Twig. In my opinion, it's easier if you do, but you can just as easily tell Symfony you want to use straight PHP templates instead.
Twig is dead simple yet powerful templating language, and is just a bunch of shortcuts to what you'll do in PHP.
There is cool built-in tools like filters to avoid inline php common treatments on strings (for example), macros and possibility of extending the language. The syntax is very clean, and easy to learn.
There is a great documentation.
Related
I need to get my Meteor JSapp in more than one language.
What would be the best approach for i18n?
Google passed my quite a bit of results but reading them I am more confused than happy. There a many hacks but is there a settled solution to this?
This is more a comment than an answer (however my repu still is too low :o):
Localization normally is only needed client side (there are exceptions but not many and they can be dealt with) and as Meteor is quite young with an own templating engine it's normal that you find more hacks than stable solutions.
However you can doge that bullet by using an older client side templating technique than Meteors built in one like AngularJS with Angular-Meteor (http://angularjs.meteor.com/). Personally I can just recommend this project as it gives you a lot more power than Blaze alone does. And now when you look for solutions for localizing AngularJS you will find a lot more. One I can recommend is angular-gettext (https://angular-gettext.rocketeer.be/) which also comes with a grunt script to extract and compile your strings in one click and which builts a .pot file so that you can translate your app with PoEdit just like you would with an old school webapplication. The only thing you may need to do yourself is to extend the grunt script to parse for any custom translation functions you may add (but maybe you can live without those than you wouldn't need to do anything).
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I'm trying to write out a list of key Drupal competencies, mainly so I can confirm what I know, don't know and don't know I don't know. (Thanks D. Rumsfeld for that quote!)
I think some of these are really broad, for instance there's quite a difference between making a functional theme and creating a theme with good SEO, load times and so on, but I'm hoping you could assume that a half decent web developer would look after that anyway.
Just interested to see what people here feel is also important. I've edited the suggestions so far into this list.
Languages
PHP
MYSQL
Query
Drupal Skills
Research and install modules to meet project requirements
Configure the basic modules and core settings to get a site running
Drush command line tool
Create a custom Theme from scratch which validates with good HTML/CSS.
Able to customise forms, core, themes without altering core files but by using template.php or custom modules.
Can make forms from scratch using the API - with validation and posting back to the DB/email
Can create custom modules from scratch utilising core hooks and module hooks.
Be involved with the community, understand the naming conventions, CVS system and ideally have submitted some code or revisions.
Modules
It's not easy to make a must know module list, as not only is the modules you use very dependent on the site, but also how you use them. However the following are widely used:
Views
Know how to make basic views and blocks.
Know how to make more complex views with relationships and terms.
Know how to use hook_views_query_alter, to make complex queries.
Know how to use hook_views_default_views, to create specific views.
CCK
Know how to setup content - what field types to use.
Know how to create your own field_formatters - the foundation for theming CCK fields.
Hooks
The most important hooks to learn, to create a basic module are probably:
hook_form_alter() - change forms without changing code.
hook_menu()
hook_theme()
hook_nodeapi() - almost anything regarding nodes
hook_schema() - create tables
hook_install() / hook_uninstall() - create tables and clean up.
hook_perm() - when you need special access control.
hook_init() - things to want always to happen.
hook_user() - if you need to tap into user actions or modify the user object.
I good understanding of client-server architecture, how servers and browsers works. And knowledge of php and mysql, templates engines. And of course, you should also read Drupal documentations.
Able to create a custom Theme from scratch which validates with good HTML/CSS and also pays attention to usability and accessibility. (Whilst still looking kick-ass).
You usually don't want to create themes from scratch but from a starter theme like Zen instead.
For Drupal you will need:
PHP, it's a PHP framework, so to really understand and use it, you need to understand PHP.
SQL, the list of SQL serves that Drupal can use is growing, but you will need to understand * SQL, relational database and how to setup some basic architecture.
Javascript (and jQuery). Drupal uses the jQuery js library, so it will be a lot easier if you not only, know how yo use javascript, but also understand how to use jQuery and some of it concepts.
The hook system and how you can alter Drupal core and modules implementing hooks.
The naming convention for hooks, theme functions etc.
Modules
It's not easy to make a must know module list, as not only is the modules you use very dependent on the site, but also how you use them. The two top modules in Drupal is.
Views
Know how to make basic views and blocks.
Know how to make more complex views with relationships and terms.
Know how to use hook_views_query_alter, to make complex queries.
Know how to use hook_views_default_views, to create specific views.
CCK
Know how to setup content - what field types to use.
Know how to create your own field_formatters - the foundation for theming CCK fields.
Another module that I find very powerfull once mastered is Panels. It allows you to do a lot of complex and difficult things with very little and simple code. There is a lot of hooks you need to learn, and not much documentation. But once you understand Panels, you find that you time has been well spent.
Hooks
The most important hooks to learn, to create a basic module is probably:
hook_form_alter() - change forms without changing code.
hook_menu()
hook_theme()
hook_nodeapi() - almost anything regarding nodes
hook_schema() - create tables
hook_install() / hook_uninstall() - create tables and clean up.
hook_perm() - when you need special access control.
hook_init() - things to want always to happen.
hook_user() - if you need to tap into user actions or modify the user object.
You don't need to use all of these hooks all of the time, but they are some of the most used ones.
Great list so far! Some others for consideration:
Ability to use Drush to update or setup a site
Strong understanding of good best practices configuration for performance, security and SEO of a Drupal site (think launch checklists)
Having submitted a module to Drupal.org (however simple) or submitted a patch (the process of getting a CVS account and getting your first code in is instructive to the community and to standards)
You don't need SEO skills for templates, drupal usually helps with SEO alot. Ofcourse a developer who will slice a design must know that all headings must be done with h1,h2,h3,h4 tags. that's really basic one. everything all is up to drupal..
as for my opinion to be a drupal "developer", you need some very basic skills in PHP. Because drupal is really written without object-oriented programing, and without DESIGN PATTERNS, so these are two things is really makes you a programmer.. without them it just [sorry for this word] bullshit not a programming.
I think anybody can install drupal or wordpress or some cms-made-simple, systems if you have at least once connected to ftp in your life... to develop plugins for them is a requires basic skills of php. Ofcourse if you'll find skillfull developer then he will know oop basic, and will write plugins with OOP and that code will be really NiCE! =)
Being able to edit existing functionality (core or module) without touching the core or module and knowing whether to put it in template or a custom module.
As we anything web related these days, you really must have a good understanding of the HTTP protocol. You also need a good understanding of JavaScript, the DOM, CSS and HTML5. Knowing a bit of jQuery is not enough for a developer, you need to understand what your are doing with the DOM, HTML5 APIs and CSS in order to build features and behaviours into the browser. You also need to understand the Drupal JavaScript APIs, both on the server side (hook_library(), #attached, etc.) and the client side (Drupal.behaviors, etc.)
You also need to known the various APIs of Drupal. The Form API is not the only one. You need to understand the Menu system (page, access, title and delivery callbacks, how to pass parameters to them, etc.), the Queue API for asynchronous operations, Batch API for long running operations, Entities and Field APIs for user editable structured data, Theme API and Render Arrays for anything presentation, Cache API, Schema and Database APIs, File API, Cache API and the Localization API.
I have recently started working with Drupal on the side and have had to tackle the limitations I come up against in the Views API. More than not I find it faster and more powerful to code it myself.
It is hard to create custom views that have a specific look and feel without create custom files anyway.
Creating the pages from scratch in a *.tpl.php gives me more choice and flexibility. I have done a couple of them now and it is almost as fast.
For a developer (since this is a programming forum) what is better in your opinion:
Views or Custom templates?
I'm not even sure what you mean by custom templates (please say you're not hardcoding SQL into .tpl.php files), but no matter what you mean, the answer is to use Views wherever possible.
Reasons:
Development speed - I promise you creating a View will be faster than a custom module 99.9% of the time
Stability - it has hundreds of thousands of testers
Security - it has the eyes of many on its code
Support - there are hundreds of contrib modules that interact with Views somehow
Maintenance - Views is a Drupal standard. Using custom modules gives your site's maintenance an unnecessary learning curve.
Upgrading - Views will provide an upgrade path from D6 to D7. Your custom stuff won't.
As for your "it is hard to create custom views that have a specific look and feel" point, I think you'll change your mind after a little time with template_preprocess_whatever() functions and overriding Views templates. You have absolute control if you want it.
Recently our newest web designer asked me why we use ASP.NET for our website. Reading through his question to the real one, I started thinking about it myself. Why are we using ASP.NET for web development?
The problem we find so far is colaboration between the design team and developers. Typically our designers create some snazzy cool look crayon laced web pages, then show them off for approval in all their glory. Once approved, the developers rip the HTML out and shove it in to ASP master and detail pages, and huzzah! out comes pretty website.
Since Dreamweaver doesn't play nice with Visual Studio, this is the same process for even small tweaks and changes. I would prefer to just write the backend and let the designers draw the pretty pictures and fancy CSS. Our current websites have plenty of reason to use ASP on nearly every page, so I can't do half in HTML, the other half in ASP.
I have no aversion to doing something else, another language, CMS platform, some other random buzzword, etc...
What are your experiences with this design situation? Are we doing it the hard way? Should we consider alternate platforms and languages? Are there any good, proven ways to allow designers to work on ASP (while still using Dreamweaver)?
Start learning Asp.net MVC as soon as possible. Designers will love you for that. :) And you'll be up to date with new development technologies that will also make your solutions much more robust and less complicated.
But otherwise. Designers should be able to read XHTML fluently. Learning asp.net semantics shouldn't be too hard. Then give then Visual Studio where they can manipulate content. As long as they know how asp.net web forms work things should be fine. They'll probably be able to do majority of things using just CSS. I know I can. Sometimes I do have to check resulting HTML, but it works.
Aside from Wicket (a java web framework), I don't know of any framework or language that would allow designers to continue to work on the design once developers have started to add logic to it.
I would suggest two things though:
Use a MVC framework - ASP.NET MVC, Ruby on Rails, Django, etc since this allows for far more separation of presentation and logic
Keep your presentation layer as stupid as possible and use helpers as much as possible or even better, put the logic in the domain objects. The view should only show or get data with absolutely no logic for processing data, this will keep the pages much more designer friendly.
I find your question very interesting because no matter what kind of technology the project uses the interfaces between the different roles will always cause some friction. I am not sure if there is a technological solution to this communication issue because the designer and developer speak literally different languages.
Depending on the skillset of your designers and developers an additional layer might help you out. I do not know how ASPX works but i am sure there will equivalents to the concepts of other technologies.
In case you have mainly static content which can be expressed in XML than you could provide the backend which delivers the content in XML with a defined Schema and your designers could describe the transformation in XHTML and CSS via XSLT. Given that your designer are capable using XHTML and CSS the addtional effort to learn XML and XSLT is not that huge. I find this solution much powerful than template languages which try to emulate the richness of the serverside scripting language in their own limited constructs. In case you have dynamic elements on the clientside like DHTML, AJAX or you name it you could define your own xml tags which are transformed to richer client side objects after the designer did their work. I guess the designer will understand the usage of these special tags and you provide the proper translation into client side objects.
I used this approach with some coworkes based on PHP. PHP was only the driver for the transformation. The content was assembled into xml with special tags which were transformed into XHTML and CSS via XSLT. Once the objects and the transformation for the different objects is defined you build up a library which can help to shorten the developement cycle of new pages of you webapplication. The benefit of the extra work is, that you designer can change the layout of the page without ever touching you server side code.
Maybe this helps.
Consider using either Expression Web or SharePoint Designer. The latter is now free.
I know you specify dreamweaver, but have you looked at Blend? It plays very nice with Visual Studio and is quite a nice app. to work with.
I have the need to build lots of sites that are very similar, but not exactly the same, using ASP.NET 2.0.
I'm trying to find the best way to make generating these sites quick and easy.
The sites will be used to collect information about a user, and there will be multiple steps for each site.
The sites will all collect similar information, but some sites may require less or more information than others. Additionally, certain form fields will need to be populated from different database tables, based on the site.
I would like to use a Microsoft patterns & practices solution, but I'm not sure that there is one that fits this scenario.
My current thinking is that I will put as much business logic as possible into an external assembly and then write a custom Web user control for each step for each site. I will include these user controls in a master page's Panel control.
I don't like this solution because each site will be nearly duplicating the code for the other sites.
How can I improve upon this design?
The main obstacle is that the sites are similar, but sufficiently different.
Thanks!
Alex
you can create base classes which handle all of the common functionality and then have your site specific controls inherit from their respective base classes and then implement their specific implementations.
We face this problem all the time. What we do is to have a common library that all our sites use, and to bury shared functionality in classes or utility modules in this library. Each site can then use those objects or utility functions as is, or extend the common classes. Keep in mind that these shared classes can include all kinds of things, including code-behind for pages and user controls that you can inherit from and extend.
Deciding what goes in the app and what goes in the common library is one of the hardest things about our business, though. Put it in the common library and you lose flexibility; put it in the app and you risk having duplicate code to maintain.
If you have a fairly complex database setup, it might be worth your time to come up with a framework for specifying your db schema in XML and having your app enforce that schema and build any additional SQL infrastructure that you need based on that definition (e.g. utility views, stored procedures, etc). We did this and it resulted in a huge productivity boost.
Have you looked into Monorail (www.castleproject.org) this is an implementation of themvc pattern, similar to Ruby on rails with a few nice view engines, I prefer Nvelocity.
from castle project as well you can use n implementation of ActiveRecord that makes life real nice. if you are on that trail also have a look at coln ramsay screencasts .
To be honest all ms solutions are real fat
another great thing about the castleproject is that is totally open source so you can learn loads from their code
How about using an Application Framework like DotNetNuke or mojoportal?
They both provide flexibility and enable you to develop websites very quickly with common functionality. Leaving you to develop custom modules where the functionality you require may be different. There are also thousands of other modules that can be bought which provide excellent functionality.
However we chose to use WCSF and enhanced upon it.
All the above mentioned projects are open source and some good examples of code to learn from.
I know it may be a late answer but I hope it helps