Bit of a vague question. Apologies.
I have a prototype CMS I've been working on for fun. It's completely written in ASP.NET MVC.
It works on the principle of "widgets". Little blocks of functionality that can be dragged and dropped on the page, you get the idea.
I have added a few simple blogging widgets which work well, one of them is the "Latest Posts" widget that goes on the front page. While the function of the widget i.e. listing the latest posts is standard, the mark-up it generates may not be. I don't want to force my users into a set in stone mark-up.
I was wondering if it would be possible to use some form of templating perhaps T4? I have not delved into it deeply but it looks fairly complex, so not sure it would even be possible. What I would like is for the end-user to be able to doctor a small template file to change the markup generated for each blog post list item.
If someone knows of any blogs/tutorials that may get me started I'd be very grateful. Googling for custom T4 templates brings up changes to the EditorFor templates that I'm sure everyone is familiar with.
Thanks,
Ian
Best idea I've ever seen on this would be to use standard ASP.NET templates and dynamically render them. You don't have to invent a programming language nor tooling and the hard parts are done for you. This perhaps could be easy to do with the new razor view syntax I'd suspect.
Related
what is the difference in performance between css templates and dreamweaver templates , or are they the same. Need to know which one gets indexed quicker by google.
I want to move my website to one the best templates for quick uploads and ftp linkups with linkmanagement tools
please advise
thanks
This is why I despise Dreamweaver and the alike...
Dreamweaver creates websites, which consist of HTML and CSS code, and maybe some JavaScript.
HTML: the "glue". It's the structure which browsers read.
CSS: the "perty stuff". It's what browsers read to determine how to make your page look (colors, layout, etc.).
Since Dreamweaver makes websites, a Dreamweaver template also helps Dreamweaver to make websites, which implies that it follows the above structure.
Templates just style your site and might provide some basic functionality, so they have nothing to do with uploads. Some might be bloated and cause slow loading times, but that's dependent upon the template.
In the end, Dreamweaver Template is more or less CSS + HTML.
A DW template file helps to isolate parts of your HTML code on a page/page basis. Editable content and "locked" content together (in hopes of making development quicker). If you like DW, and have a template you like - 0use it. But don't expect that to be your silver bullet.
There's no advantage to either template where search engines are concerned (good/bad content withstanding).
Content...(pertinent content) is what Google is after. Having a 1M file of valid content will beat a 200k file of sparse/bait-n-switch content every time (well, it's supposed to, right?).
The answer you are looking for: Every Dreamweaver template is a CSS+HTML template. So it depends on the CSS template you are using. For the most part Dreamweaver is pretty bad about writing optimal CSS and it also uses inline styles which is bad for performance.
The real answer: It is obvious you are a beginner and don't know how silly your question is, it is not even one question, and is open ended and has no answer. There is no such thing as a CSS template, CSS by itself is not enough to create a template and this is just a marketing word to use to sell templates to people looking for such a thing as a better alternative to HTML templates, and etc, there is CSS for a certain type of template or certain Document Object Model, so if that is your definition of a CSS template than every Dreamweaver Template is a CSS template, as Dreamweaver itself is not a web technology or language. Dreamweaver is a WYSIWYG/IDE that helps you to write CSS (and other code) without knowledge of CSS, or in my case I use it because I love the pink/purple syntax highlighting it has for CSS in code view.
*Need to know which one gets indexed quicker by google - FTP Upload - linkmanagement *
This has nothing to do with your question, you can create a website in notepad that gets better SEO results. You are mixing all these different concepts together, SEO, CSS, HTML Templates, google indexing,templates, quick uploads, ftp linkups, linkmanagement tools, these are all different concepts and each require years of experience for you to achieve this. At the end of the day what I am trying to tell you is, building a website as you describe is not a few clicks to create a template with dreamweaver. You first need to learn enough to be able to ask the right questions. And then you will be able to create such a website, not the best and ultimate "templates for quick uploads and ftp linkups with linkmanagement tools" but something that works, even though I'm not sure what exactly you are trying to build.
I Think you should look into a CMS like WordPress and get a nice looking wordpress template for your site and eventually become more familiar with these concepts. WordPress has a really good SEO/(google indexing as you say) that it even gets better results than expensive websites built by professionals. This is definitely what you want! trust me!
http://wordpress.org/
I'm migrating a site from a proprietary cms (reddot) to drupal. For all its flaws, reddot has a very simple yet flexible model:
templates consist of markup with placeholders for variable content
every piece of content, from a full page, to a shared piece of sidebar content, and even a single image can be built from a template, if an appropriate one exists
My first impression of drupal is: woah, this is complicated! Rather than three simple objects, now i'm dealing with nodes, pages, blocks, regions, views, panels, etc. What is the simplest way to recreate the template/content/placeholder model that i'm familiar with?
Reddot uses a rather well architectured MVC-alike system. In addition, from my limited experience, Reddot follows the there is only one way to achieve Foo-philosophy.
Coming to Drupal, especially as a frontend-developer you will be dissapointed, lose a lot of hair and probably curse a few times when you realise everything has to be done all over again.
Coming to Drupal you will love the gigantic amount of (unfortunately unorganised) documenation and its flexibility and enormous amount of new posibilities.
When people come from properly architectured systems into Drupal, I advice them to do one thing: become pragmatism-exstremists. Don't (ever) try to make things proper, clean or well-thought out. You will only be able to do that once you truly grok Drupal. And that only comes with a lot of experience. Just fiddle untill it works, close the code and never look at it again.
First thing you will need to learn, is Drupals PHPTemplate engine, which is rather different from Reddots, but has a lot of similarities. Where Reddot uses RenderTags, Drupals PHPTemplate uses plain old PHP.
<%!! Context:CurrentPage.Template.Name !!%>
becomes
<?php print $name ?>
And yes, $name is entirely globally scoped. Remember? I told you to be a pragmatism-extremist. Don't even think about namespacing, object scoping and such.
Want to know what variables you have available? Just do a <?php print get_defined_vars() ?>.
Want new variables in your template? You need to preprocess them.
Want to change, alter, strip or modify existing variables? You either need to preprocess, or template override or even write new modules that make new or different variables available?
Knowing which to choose, when to preprocess, when to create modules, when to override, when to implement hooks to alter stuff is experience.
Drupal has never thought that out clearly, there is no general rule or best practice, other then the last eleven times that Foo-concept did not work out, maybe Bar proves the best.
Drupal's templates are similar to what you describe of reddot, but there are probably more options and they can be nested. To get a good sense of how the templates work together download the Theme Developer module and watch the associated screencast.
To get a sense of the "placeholders" you can use in a given template, visit the api.drupal.org page for the template file or check out this Drupal 6 Theming Cheat Sheet.
Another one bites the dust.. ;)
Let me know how you go with the migration Bobby Jack.
I think for the content you might be able to create an XML variant in the CMS and export everything to re-import it to Drupal..
On the Drupal note: Once you get your head around the concept of templates being able to inherit/being overwritten it's easy.
It's like a set of pre-assigned content classes in RedDot which can change to render them in a different layout. Similar to the "replace content-class" functionality.
I've been coding in PHP for 4 years and even I find it so convoluted and hard to grasp. I have no idea how they expect designers to manage theming.
I know basic theming, theming with tpl files, views templates, contemplate templates etc. However I get lost whenever I enter the template.php file.
I needed to theme a node input form for a custom content type. I wracked my brain over it with like 7-9 tutorials and it's still not coming together. I understand why module building can be complicated - because most people who work with modules are developers anyway.
However, when even a developer can't understand theming, it's definitely over-engineered!
Maybe it's my fault, maybe I didn't learn Drupal properly. In that case, is there a step-by-step system to becoming a Drupal guru?
Theme is really not that difficult, if you only know basic php. You have 3 ways of altering the markup, the css and js, you should be able to handle.
Template files. By creating a template file in your theming and naming it correctly, it will take precedence over other template files, and you can thus create custom markup for views, nodes etc. By creating a template for a noce type, you can do stuff like printing out the cck fields in any other instead of using $content. All you need is on the node object.
Preprocess functions, which are placed in your theme, will give you the possibility to add or alter variables that will be used in your template. You name the functions like hooks: yourtheme_page for the page template yourtheme_node for the node template etc. Here you can create some custom logic, or modifications, to help make your templates more clean and just handle the printing of the variables.
Theme functions. You can overwrite theme functions to alter the markup that's used. You only need to create a function called yourtheme_[theme_function_name]. You don't need to understand much php to do this. Often, you can just copy the original theme function, and make a few alterations in it to get the markup you want.
With the above you can do 90-95% of what you need. Forms are a bit special since you in Drupal 6 can't alter them (easily) in your theme. Instead what you want is to create a small module and use hook_form_alter, which allows you to modify the form, text used on buttons etc. This is changed in Drupal 7, which will be even easier to theme.
So it really isn't all that complicated, just use the 3 basic tools described above. The tricky part can be to name your functions and templates, but devel themer can help you with that. Another tool you use is devel which can assist you in printing out variables so you can inspect them and see what you have available, fx CCK fields on the node.
Maybe you should get a copy of Front End Drupal.
In my opinion, Drupal theming is not difficult once you wrap your head around the concepts like templates, overrides, .info files and preprocess functions. Those things are not directly related to php skills, it's all about understanding the system.
It's interesting to see that you're a themer, yet you only talk about php, not CSS and HTML. In my experience, a lot of theming tasks can be accomplished with CSS, without even touching php.
Finally, I don't know if you are using a base/starter theme (like Zen or Genesis) already. I recommend using a base theme and realizing your own design as a sub theme.
Most people get an 'ahah!' moment when themeing suddenly starts to make sense.
I'd argue that this is probably tougher for experienced PHP developers, since you have to get past a lot of concepts that don't make sense in vanilla PHP ("the function is magically called at the appropriate time ... because of how it's named?!")
#googletorp's answers is pretty comprehensive, so I'll just add some practical tips that helped me along:
1) Try building a module that implements it's own themeable output and simple hooks. Hooks and theme functions make a lot more sense when you see how modules are actually calling them and using them.
2) Make liberal use of the devel module, especially the Theme Registry menu (note how it changes when you add a new theme function), the 'Render' tab, and the dpm() and dvm() functions
3) Buy a old-tyme dead-tree book on Drupal themeing. The online docs are really outstanding if you already know what you're doing, but can be extremely confusing if you're not sure what you're looking for.
4) Empty your cup. At the theme level, PHP is really just for simple logic and syntax -- almost everything of substance is getting handled by Drupal API functions. Try to think like a Drupal developer and not a PHP developer (i.e. don't assume you know how to do something just because you built a vanilla PHP site that does the same thing) and you'll have an easier time.
Keep with it! The theme system is actually really easy to use once you've figured it out.
to answer your question on why it is so hard:
Drupal themes may seem overwhelming, due to the sheer amount of possibilities, see #googletorps answer for a good overview.
Having "many ways to do one thing" brings power: power users can choose the best of all possibilities. But it also brings complexity: new users don't get a good lead, because there is no "you should do it this way. fullstop."
Alongside that amount of ways to get stuff done, there is the problem of nesting. Drupal has a concept of very deeply nested items. To take a random, yet simple example:
username<menuitem<menuitem<menuitem<menu<block<region<page.
Will render a menu-item, containing a username in a three level deep menu-item in a sidebar-block.
Where most templating-environments have concepts of a page, containing several "contents" that, at most, might contain some partials. the nesting is at most three levels deep. And each level has a clear, distinct area of expertise. Drupal does not have that: the nesting is fairly arbitrary. And each nested item is no different from its parents. This, again, offers power-users a great concept and power to work with, but is hard to grok for new developers/designers.
Lastly, another reason why it is hard to learn, is that the Drupal online documentation is more a wiki then a read-from-begin-to-end manual. There are great books that fill htat gap, you will have to buy them, though.
If you haven't seen it already, this is a great presentation on why Drupal 6 theming is difficult and how it is improved in Drupal 7. There is hope! The video made more sense to me a second time watching after more experience theming.
http://sf2010.drupal.org/conference/sessions/design-and-theming-whats-new-drupal-7
One of the biggest tricks is to override something that is normal rendered with a theme function into a template. This gives you much more control over the markup, and also lets you use the preprocess functions to manipulate the variables before handing it over to the template.
This is a huge boon to theming forms. See a short video that explains it better than I could here: http://drupaldojo.com/session/fine-tuning-ui-theming-forms-drupal-60
(I've posted this on the drupal forum too btw)
I'm converting the company websites to use Drupal, or at least trying to check that its going to be the best way forward. I have a background in PHP development, and I'm currently using the CakePHP framwork. I've built this site (not my design) and I can see how to replicate most of the functionality using Drupal, most likely using the CCK module.
http://preview.tinyurl.com/yk6u8mt
As you can see from the homepage:
A user chooses a country.
The country is passed using an ajax call to a script that decides which phone is best based on 'in country' network coverage.
A div is shown recommending the visitor the best phone for that country.
I'm wondering how to go about this in Drupal, I'm definitely not after a step by step guide, I just want to know if this kind of thing is possible with Drupal, and what approach to use.
If someone can help that would be superb. Thanks.
Okay, so you've got a path you're defining in hook_menu, which is where your form is being presented - or else you've got it set up as a webform in a node, that could work too.
Either way, in your form you're going to be using AHAH - check out http://api.drupal.org/api/drupal/developer--topics--forms_api_reference.html/6#ahah and http://drupal.org/node/348475 .
Basically, you're going to define another path in hook_menu that's of type MENU_CALLBACK, and which will receive the country as input, and then will return the div that you'll display on the screen.
One core example of AHAH that may be useful to you is where you're entering a password and it lets you know if the password is secure enough - check that out.
Edit: There's also some good examples at http://drupal.org/project/examples.
I would look into using CCK and views. you can set up filters for the views. If filters don't work, you have the ability to include php code. I have also successfully added jquery code in the header of a view through which I was then able to have my view filtered by what is typed in a text box.
Coming from CakePHP using Drupal is a pain in the a** - even more for developers.
It's application structure might be designed to ease extensibility but this only means you have a system to enable your own plugins and themes.
While modules are basically the M+C-part the themes are the V-part of an MVC-application. The problem is that this seperation is not very strict in Drupal - in fact you have to break it sometimes in order to make things work (e.g. you have to include a theme_mymodule_myfunction() into your module as default output which you then can override with your theme using mytheme_mymodule_myfunction() ) And don't even bother looking for classes ( see http://drupal.org/node/547518 ).
Also there is no real link from a module to a theme. On many occations this is a good thing as you can switch modules and themes seperatly without creating a problem. For application builders coming from CakePHP (or any other framework) you often feel a lack of "wholesomeness" - you create parts for a base software and have to live with it's drawbacks.
IMHO I wouldn't recommend this step. Drupal is fine if you have to manage a website and might add a few modules to add neccessary value (image gallery etc.) but I definetly don't recommend it as a base for a customized web-app.
I downloaded GraffitiCMS the other day(now open source and free), and like a lot of what I see, but what I really want to use it for, is to add CMS capabilities to an existing asp.net database/application.
Without getting bogged down with all the details of my app, can someone give me the basic 'approach' that should be taken to add custom content to Graffiti; content that won't be a 'post'?
I've seen for example, how to add custom-widgets to Graffiti - basically inherit from the widget class, compile your dll and plop it into the correct directory and it becomes part of the system. Is there a way to do something similar for the main content areas?
For simplicity sake, pretend I have a non-graffiti database with gig's of data that I want to display on the website using standard asp.net grid's and forms. I realize I could just go in and hack apart the source code to integrate my existing app, but that is likely not the correct approach.
Not looking for a complete solution her, just a pointer and what areas to investigate...thanks.
If you check out the latest source of Graffiti (or the 1.3 branch that was recently created), support was added to put widgets anywhere you want on any page. There is a new chalk function - $macros.Widget - that provides you with this ability. Dan Hounshell wrote a blog post on how you can use this new functionality:
http://danhounshell.com/blog/graffiti-cms-1-3-add-a-widget-anywhere-in-a-view-with-new-widget-macro/
If you're looking for something different than that, just let me know - we're working to make Graffiti even better for situations just like you are currently in.
What we have done to be able to integrate Graffiti CMS with our current ASP.NET projects is to create a post in Graffiti called "hidden" and then with our standard .ASPX pages we call a class in our Render Override that pulls the "hidden" post (ie: site.com/hidden/) and uses the header and footer to wrap the Graffiti theme around our custom .ASPX page. We use some HTML comments in the "hidden" post to be able to parse the header and the footer. It is kind of a hack, but has worked out really well for us.
I think you're trying to put the cart before the horse - depending on the size and amount of functionality, I would be looking to rebuild it after learning the development platform of my CMS system of choice.
I'm pretty much in the same boat right now. I have avoided Graffiti because I have to learn "Chalk" (whatever that is) and Umbraco (using XSLT for layouts is retarded). So far, this leaves me with Sitefinity at the top of my list and Telerik have just pulled the free version!
I may end up grabbing a very basic CMS which is easier to customize. I know this doesn't directly answer your question, but it may give you some food for thought :-)