I know, it's a naive question :-)
Originally poped up into my mind over Zope 2: How to properly “browser:page” to make a page available everywhere?
Views are callable adapters that provide output based on the context and the request.
Templates are callables that render a piece of text based on a template. They are often used in views.
Note that views can return text without using a template:
from zope.publisher.browser import BrowserView
class MyView(BrowserView):
def __call__(self):
return "Hello world, I am located at {0}".format(self.context.absolute_url())
Views can also be used by other Zope code, without themselves being published. Zope code uses a lot of views internally.
Related
I am a newbie in MTurk, and I am trying to create a very simple Categorization Project via their Requester UI (rather then the API).
Each batch I use has 10 items (question and possible answer). I have searched their documentation and forums with not help and so I have several questions:
When i use their Standard Categorization template, I have no option for modifying the HTML and layout (as shown for "Tagging of an image" project). the only formatting options are for the categories, instructions and includes/excludes. Is there a way to edit the HTML of the standard template they provide?
In the Standard Categorization template, while my input data file (csv file) contains 10 items, only 5 are shown (tried with 6, still only 5 are displayed in the preview). Is there a way to change this limitation?
When I try to use the "Create HITs Individually" (rather than the standard template, as explained above), I have the "Design Layout" options, but I cannot find a way to make the questions in the "form" required (which is possible via the API). Is there a way to achieve this?
If you stick to the standard project templates, you can't modify them. That's the reason to create HITs individually (through the RUI or via the API).
You'll have to show us your CSV file, because it's not really clear from your description what the issues could be.
Your third question is unclear, but basically for creating HITs individually, you simply do standard HTML markup and put in ${variablename} placeholders wherever you want one of your CSV upload variables to be placed.
If your project is at all large, I would definitely recommend going through the API. It's simply much more flexible than the RUI for creating any kind of customized design.
I'am modernizing a legacy web application, with its frontend based on ExtJS 3.x.
Currently, user interface depends on large file of several thousand lines, with too many nested anonymous functions, encapsulated in an global `Ext.onReady()̀ per file. It's ugly, unreadable and not maintenable.
To maintain code and modernize it, I want gradually refactorize it by :
using namespaces
exploding big files : one class per file (grid, store, form ...)
organizing class files in a good directory structure (app/module/grid|store|...)
loading dynamically class files, when required (maybe with Ext.Loader.load() ?)
optimizing loading by using minifier, as assetic, if possible (in a next step).
All these problematics seems natively solved in ExtJS 4, with its class Loader, its dependency system (require), its Application Singleton and its structure folder conventions...
In ExtJS 3, it seems more confused. So :
What are the best practices in extjs 3 to organize code "like" in extjs 4 ?
Do you have clear examples illustrating these problematics ?
Ext3 is an entirely different beast than 4. Code organization is really up to the developer. I personally would avoid dynamic loading in favor of minification of the entire app. This is what ext4 would give you in a production app. They really only intend dynamic loading for debugging purposes. I have gone the dynamic loading/module route before with Ext3 and it was a regret. It is OK with 4 with it built into the class system.
If you are using a later version of 3, do namespaces with Ext.define. It will do the Ext.ns for you internally and will make upgrading to 4 easier down the path.
You are correct that you shouldn't have big files or config objects, but don't go too overboard. Try to group things into logical classes. A grid can be part of class that contains other components that make sense as a view.
If you do want to upgrade to 4 later, I would recommend trying to emulate the structure a little at least with stores and views. 3 doesn't really impose any structure.
I would avoid dynamic loading with 3. See above.
Definitely minify. Not only will there be much less data going over the wire, but you get huge savings by removing all the overhead of a GET for each script. Gzip might help a little too.
if I'm using rails 3 which uses asset pipeline to compile all
Javascripts, does that mean I can have only one Knockout view model for my entire application? If not, how do I specify which view model is binded with which view? In the tutorial code, it looks like 1 view model is bound per page, but that doesnt work in rails since all JS are loaded upon first page load.
No, you do not need to include all javascript on every page! This is a very bad idea.
There are many methods for limiting javascript to a single page, you should pick one:
Method 1
Method 2
Method 3
Please, please, please do not try to load all your javascript on every single page.
Update (after your comment below):
I think you are confusing a few different things here.
First, even if you compile all your javascript into a single gzipped/uglified file, that still doesn't force you to use one knockout viewmodel for your entire application. That file can contain multiple viewmodels. They don't even need to know about each other.
Second, the way the rails pipeline works is by concatenating related or dependant javascript files together. It does this to reduce the number of requests the browser has to make to get the javascript it needs for each page. It doesn't necessarily mean all your javascript becomes one file. Just that the javascript for each page become one file. For more information, check out the Rails Asset Pipeline Documenation, it has a great explanation of how it works and how to use it properly.
Third, neither of these things mean you need to write all your javascript as if it were one file. In fact, this is a bad idea. You should seperate your javascript into relevant files by functionality. This allows them to be reusable, as well as eases development work.
Hi guys : I have a "hierarchichal" styled site in compojure with a defroutes declaration like so :
(defroutes main-routes
(GET "/" [] (resp/redirect "/public/index.html")
(GET "/blog" [] (resp/redirect "/public/blogs/index.html")
(GET "/tools" [] (resp/redirect "/public/tools/index.html"))
I would like, however, for these pages to be more dynamic - that is, I would like the index.html page to be generated by scanning the contents of the /blog directory, and likewise, for the /tools route.
That is, in the end, I would like the routes to look like so :
(defroutes main-routes
(GET "/" [] (resp/redirect "/public/index.html")
(GET "/blog" [] (generate-index "/public/blog"))
(GET "/tools" [] (generate-index "/public/tools")))
Is there a simple roadmap for building dynamic paths through my site via compojure ?
More concretely ---- are there any suggestions on how to build a (generate-index) function which scans the inputted path and returns links to all files ? I assume that compojure might already have such a feature, given the recent rise of so many blogging platforms which are based on this type of idiom.
Doing most of what you said is fairly simple.
There are two things that you are going to want to look at in particular, as well as some general reading which will help you understand what's going on.
First, you are going to want to take a look at some form of HTML Templating tool. While it is possible to just build the necessary strings, things will be simpler if you use one. I've seen two different main styles for them, and which to chose depends on your tastes.
Hiccup is focused on taking Clojure data structures and transforming them into HTML
Enlive is focused on taking HTML template files and transforming them into the correct end form
For actually getting the list of files, consider using file-seq. Transform the file name into the appropriate post name and file, and then use that as data to generate the links to the pages.
The other thing you're going to want to learn more about is Compojure route templates and a little more on Ring Responses.
Compojure's route templates make it easy to pass in route parameters which you can then generate responses from. Following this is a simple example which serves a simple static html file using the html page name as the parameter.
(GET "/blog/:post" [post] (ring/file-response (str "/public/blogs/" post ".html")))
Finally, consider reading through the rest of the Compojure and Ring wikis. The Ring wiki gives some very good information on the core "how things work". The Compojure wiki provides some good examples on how to best make use of Compojure, which just focuses on providing an easy way - but far from the only way - to handle the routes and make the page generation for Ring easy.
Depending on where you want the site to go, I'd also consider taking a look at Noir, which is a framework that does a nice job at pulling together all the pieces and solving some common problems in the process.
Currently I'm trying JSF 2.0 and still learning the more advanced features.
JSF2 is comfortable when having to deal with pre-defined views (fixed component trees) whose widgets are completely known at compile time -- of course with the exception of repeating data list/table entries and light dynamic modification of forms via the DataTable "trick" (as I read here, especially under JSF2, can I add JSF components dynamically? and How to create dynamic JSF 1.2 form fields).
Now I'm wondering about the realization of completely dynamic JSF2 component trees, where a web user, for each given content type (e.g. 'Person', 'PersonList' but also 'PersonalManagementPanel'), can choose one from a list of content-type compatible widgets (=JSF custom components).
As result, this user will always see the "Personal Manager Page" rendered with his/her prefered "PersonalManagerPanel", which in turn also renders its nested components ('Person', 'PersonList') with the user's preferred variants.
Obviously, the goal is to get a selectively configurable/customizable JSF Page -- at runtime.
Is this scenario realizable in JSF2? -- How could this be done?
Are there more appropriate Java technologies for this requierement?
-- One possible alternative I'm thinking of is XML plus XSLT.
Thank you very much for your help and suggestions.
Best regards
Martin
You can use something like this:
<ui:include src="#{bean.template}" />
Or if you want more complicated components, you should take a look at the PreRenderViewEvent.
Note that there are issues with both solutions.
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-770
http://java.net/jira/browse/JAVASERVERFACES-1708
http://java.net/jira/browse/JAVASERVERFACES-2041