I am currently involved in a Django project and I am definitely using Twiter bootstrap for the layout.
Though not actually precise, my question is quite simple: Bootstrap allows me to choose which styles/JS I want to download separately -- forms, tables, responsive, styles for buttons, navigation, etc -- and also together in a single "all-inclusive" file.... and I am not using all the resources at once on the same page.
Additional to that, we have the Django template system, which allows me to build one template over another, so I can basically add the more general stuff to my base template and, as I need in subtemplates, include the other static files.
So, to sum up everything: Is it worth it, to have those styles separated? I think that in terms of organization maybe it is not so clean, because I will have to import and handle more CSS files, but on the other hand I won't be loading unnecessary stuff.
What are the trade-offs of this choice?
Thank you for your time.
Is it worth it, to have those styles separated
No it is not. If you look around, e.g. visitmix, you'll see that the overhead of requestig new files make the difference neglible.
Server you static from a cookie-less domain and you'll users will only have to hit your servers twice: once for CSS and once for JavaScript.
Related
I would like to do a project with TYPO3 v10 I'm new with this CMS and I need to create different templates for different pages but I don't understand which code I need to change.
I already install a sitepackage from this site https://www.sitepackagebuilder.com/
It work well but I need to create my own templates and I want to edit the content of my templates in the back end administration like in the picture.
I hope I'm clear
thanks for help :)
I am not sure if there is a misconception in the question or if I have interpreted incorrectly. In any case, I hope this helps:
It is important to differentiate between content + template in TYPO3:
content
In the screenshot posted in the question, you see the TYPO3 backend, which is a view for editing content, administration etc. There you see the page module is opened in the left column (1), you see the page tree in the middle column (2) and the page layout for editing content on the selected page in the right column (3). Here, you can insert and edit the content, that will be displayed on a page.
Template
In TYPO3, the template is what makes up the automatically generated parts of the page such as header, footer, menu, breadcrumb etc.
It work well but I need to create my own templates and I want to edit the content of my templates in the back end administration like in the picture.
Editing the template in the backend with a Wysiwyg ("what you see is what you get") editor, similarly to editing the content is not really possible in TYPO3 AFAIK - at least not out of the box. For this, you would need a template builder. The only thing I have seen so far that comes close to this is toujou (I am not affiliated with them, just wanted to mention it). They have something which you could call a website builder. But AFAIK, you can't download it, they provide this as a service.
The sitepackage builder - as far as I know - pretty much just creates a sitepackage based on the bootstrap package extension which you would have to further modify by editing the files.
What you can also do is edit the TypoScript in the backend. Just go to the "Template" module in the left column. But, this made more sense in the past, because a lot more was done with TypoScript. Nowadays, you usually use a combination of Fluid and TypoScript and you can't edit the Fluid files in the backend.
While in the past, a lot more was done in the backend or could be done in the backend, everything is moving towards maintaining changes in files and extensions, where the template is maintained in a sitepackage. For some things both is still possible (backend and extension), e.g. backend layouts, TypoScript etc.
Moving the configuration + templates from the backend (and storing them in the database or as files) to a dedicated extension has several advantages:
Every configuration etc. is bundled into one extension, this makes it easier to install in another site, on a testsystem, exchange it etc.
the sitepackage can be put in a version control system (e.g. git) which has a bunch of other advantages such as easy rollback to a previous version, referencing issues etc.
The downside is that you need more technical expertise and there is a learning curve.
see also:
The Anatomy of Sitepackages
Sitepackage Tutorial
I understand that it might be pretty cool to assemble a template in the backend - just like you can do with the content. Maybe someone else knows how to do that with TYPO3.
You can also check out these resources which seem to go in the direction of what you are looking for:
TYPO3 extension mask (documentation)
T3terminal
in the official documentation you can find the structure of folders where the files for your layout are stored.
More details on fluid templating in this document
Now you want a possibility for editors to select between different page layouts. An often used way is to use the possibility to select different backend layouts and select a frontend layout accordingly.
This is shown in the video on this page or in the documents you can find if you uses the searches on that page.
With the new KnockoutJS native DOM-enabled templating life's gonna be easy.
But sometimes pages contains millions of them, and all templates are static or just i18n'zed. So it would be great to retrieve templates from server via separate HTTP calls, so the browser will be able to cache them as static files.
It will give a great reduce in traffic and whole server load! Pages will be light and contain only changed data. Templates stored in CDN. It's a dream!
It was possible with jQuery.tmpl and require.js. But how to do it with knockout itself?
It would be perfect to load templates by name on demand, like an php __autoload() for templates, but at least it would be great to somehow include templates as remote html files to the page, and parse them for knockout.
Do you know how to do it?
There are several ways to accomplish loading templates from external files.
In my opinion, the best option is to use the Knockout External Template Engine available here.
If you want some more basic ideas, I had a post from last year that describes some thoughts on the topic here.
I'm new to Django and fairly confused about how third-party apps are best integrated. In my (possibly naive) interpretation of DRY, I want to minimize copy/pasting not only my own code but other people's code as well, so I'm happy with, for example, the pattern of using contrib.auth as mostly a black box if I needed additional info on auth.User (by extending auth.User with a UserProfile object or inheritance). And this was how I imagined I'd use most third-party apps as well.
However, I quickly found out this was very difficult, so now I've resigned to having "copies" of all of my third-party apps living inside my project folder that are basically entire copies with minimal changes. The final straw was me wanting to add a basic blog (I settled on django-basic-blog) and needing to just change a single template, and I thought of no better solution than just making a copy of that app inside my project with the single template changed.
My questions:
in this specific case where I need to change just a single template, is this (copy the entire app over) the best I can do? If I just needed to change a single model I can keep the third-party app respectfully intact and do a model inheritance in my own app...
in general, this practice of copying the apps under my project and patching each a tiny bit feels crazily wasteful and dirty. It also feels like if I'm using a frequently-updated third-party app it will be a pain to sync the changes. Should I just learn to love the bomb or is there some obvious architectural pattern / Django-provided assistance I am missing?
You should not modify the code of 3rd-party modules, as it's hard to track the changes and it creates a mess with the same code copied into many projects. Typical solution is to have only one version of each third-party module in your python path, not in your project's dir. This single package can then be reused by all of your projects.
However different approach is needed for templates, as they often need to be modified on a per-project basis. That's why Django comes with settings.TEMPLATE_DIRS and settings.TEMPLATE_LOADERS.
TEMPLATE_DIRS specifies list of directories containing template files. TEMPLATE_LOADERS specifies the classes used to load templates. The loaders will be used in order they were defined and the directories will be traversed in order they were defined. So you can look for templates in your project's directory first and in other modules as a fallback.
So basically you do not need to copy the entire python module in order to change one template. Copy just the templates directory of that 3rd party module or even just the single template you want to change. If you'll put in the right place and add have the path in TEMPLATE_DIR Django will use it.
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.
I'm starting a a new application, and want to concentrate on making it modular. What I mean by that is that is that in my head I envisage some basic facilities log on, user roles, layouts etc but then I am looking to be able to be able to add self contained "chunks" of functionality e.g. document repository and upload, diary and reminder service .. whatever.
How I've been laying out apps so far is simply everything in root, separate subfolders for images and cfcs, sticking to naming conventions for variable and query names etc, all database interaction via cfcs, doing all my processing at the top of the page, then a comment line then display/page layout below that.
I have tried and failed to get my head around the various frameworks out there, but I just get paralysed with indecision and confused about whether I'm doing it "right". Is there a way of working that has some acceptance of being a useful methodology without getting in to the whole official "framework" thing?
Then you probably want to separate your presentation layer from the core as much as possible. A good and popular way to do this that is picking up speed very fast is following the MVC (model-view-controller) pattern
http://en.wikipedia.org/wiki/Model%E2%80%93View%E2%80%93Controller
This will allow you to modulate functionalities into controllers that are completely seperate from layout, etc. The controllers can then more easily be integrated into other projects as need be.
I know you said you didn't want framework and you most certainly don't need one but I strongly suggest it for larger application such as what you are describing. Some can have so many rules and what not that they seem to get in the way a lot. One that I like, which is based on Ruby on Rails called CFWheel (http://cfwheels.org/).
It's pretty much there to help you structure stuff, you are free to follow the "normal" way or not it won't really stop you. Have a look at the screencasts here: http://cfwheels.org/screencasts
Model Glue is an excellent CF Framework. The google group support + docs are great.
FW/1 is another simpler framework to start learning, not sure about the docs at this point.
Frameworks are definately the way to go. Once you get your head around them, they just feel "right". They tend to make you write better code, and having used a coldfusion framework for a year or so now, I can honestly say I'll never go back to not using one 8-)
Honestly, the frameworks can lead to analysis paralysis quite easily. You can easily over think things. Here is what you do, keep it simple and just bang away at the keyboard. Use your "own" framework. It might not be pretty, but you'll get it eventually and you'll see why the other frameworks exist.
Here is how you start:
Create folders layouts and views. Put all your page layout stuff in the layouts folders (you'll probably have only a few and maybe even one layout)! Put all of your view stuff in the views folder (this will probably look like what you've been doing with a bunch bunch of files not very well organized). The key is that you won't have ANY page processing "top of page" code in your view files.
Your index.cfm will be the only .cfm root. Use a URL variable "event" = action to make your framework go.
In your index.cfm, use a giant cfswitch to determine which "top of page" code to execute (this will be a giant "controller").
mysite.com/index.cfm?event=contactInfo
<cfswitch expression="#url.event#">
<cfcase value="contactInfo">
<top of page code>
<cfset structLayoutInfo["pagetitle"] = "XYZ Contact Info" />
<cfmodule template="/layouts/mainlayout.cfm" attributeCollection="#structLayoutInfo# >
<cfinclude template="/views/contactInfo.cfm"/>
</cfmodule>
</cfcase>
.....
</cfswitch>
Combine this with the cfmodule tag to load your layout. So, all your page requests come in through index.cfm. Index.cfm will do all the top of page stuff and then do a cfinclude to the appropriate view in your views folder. Use the cfmodule tag to load your layout (check out the tag.execution mode stuff for headers and footers).
You'll keep adding features and adding features to your framework. You'll probably move the index.cfm code to a controller folder with a bunch of CFCs that call your database CFCs.