Extra fields in the (upcoming) admin
Marc Worrell
As a result of the earlier discussion I added a simple mechanism to add 'blocks' to the admin.
Currenly I only added a 'header' and a 'text' block.
The header block is meant to be shown as a header.
The text block is a html block, just like the body.
The blocks are (at the moment) just a simple list, no nesting.
Every block has an optional name.
You can address a block by this name in the template, for instance:
m.rsc[id].blocks.extra.body
or
m.rsc[id].blocks.extra.header
Next is to add an extension mechanism so that we can have some more interesting blocks.
Another thing I am thinking to add is a hierarchy editor for collections.
This can be very helpful when you want to change or make a hierarchy of pages (like in a book).
The current nested hierarchy editor (like used on the category page) can be used for this.
- Marc
PS These changes are available on the "new-admin-design" branch of Zotonic [1]
[1] https://github.com/zotonic/zotonic/tree/new-admin-design
Dmitrii Dimandt
Dmitrii Dimandt
Marc Worrell
Maybe using a fold notification over an observe_admin_block.
Or we go digging for all the templates of the format:
_admin_block_li.mytype.tpl
and/or
_block.mytype.tpl
Where the second one could be used for display purposes.
On 3 apr 2012, at 17:51, Dmitrii Dimandt wrote:
> As declarative as possible. WIth possible options like
> {value, value | function_to_call_to_provide_a_value} (e.g. for combo boxes etc.)
You mean for the selects in the admin?
- Marc
Arjan Scherpenisse
available to you depend on the category of the rsc you are currently
editing.
Content blocks only make sense in a context, and that context is the
category.
Still need to look at the code, but I presume blocks can be arranged etc?
mod_survey currently has its own "block"-like implementation of
arrangeable questions. I think if we can make the blocks
category-dependent somehow we can refactor mod_survey to use this. The
current mod_survey architecture has annoyed me for some time already :-)
Arjan
Marc Worrell
On 3 apr 2012, at 20:45, Arjan Scherpenisse wrote:
> What I think would be the killer feature: have the types of blocks
> available to you depend on the category of the rsc you are currently
> editing.
>
> Content blocks only make sense in a context, and that context is the
> category.
True.
> Still need to look at the code, but I presume blocks can be arranged etc?
Yes, you can drag them up&down.
> mod_survey currently has its own "block"-like implementation of
> arrangeable questions. I think if we can make the blocks
> category-dependent somehow we can refactor mod_survey to use this. The
> current mod_survey architecture has annoyed me for some time already :-)
mod_survey will get a refresh, not in the least because I need a translatable version :)
I think it must be simplified, and extended.
At the moment it is a nice proof of principle :)
So we need some block definition like:
-record(rsc_block, {type, title, categories}).
Where categories could also be 'undefined', meaning all categories.
I propose to have the edit/display template directly derived from the block type.
_admin_block.mytype.tpl
_block.mytype.tpl
Do we need extra "before update" routines?
Or do we just let the block-module hook into the resource update notifications?
- Marc
Arjan Scherpenisse
Sounds like a wonderful plan! Looking forward to it :-)
ll...@writersglen.com
As I mentioned earlier, I'm a bit uncomfortable with some of the names used for important Zotonic concepts. For me, they create mental fog in two ways:
-- Some of them have an explicit technical meaning in Zotonic that may or may not be well defined in documentation (thanks Andreas and Michael for your help with resources and edges).
-- Some of the terms have other meaning in other contexts (I don't know if it's still used in Zotonic docs, but the term "page" for what I'm presuming is now called a resource, really threw me off when I first came into Zotonic, having confused with html page.)
For me, having a firm conceptual model with terms that have clear and explicit meaning makes all the difference in how quickly I can learn about a complex system like Zotonic.
At risk of confusing the waters and, perhaps, sounding tediously pedantic, let me share some things I've been thinking about web development. I throw this out not to impede current work-in-progress, but as food for thought and discussion related to future work.
1. The browser sees streams of simple text stings and binaries.
-- Strings and binaries, in other words, are the products of all the logic we cobble together to create our web development tools.
2. These streams are formatted to represent human-readable text, links to images, html markup, css markup, and javascript
-- They embed and intertwine information for both the machine and the human consumer.
3. Since the strings are too extensive for our limited minds to process as a whole, we "chunk" them into conceptual components that we call resources, templates, css styles, etc.
-- Other frameworks may well use different terms for the same concepts, which can contribute to possible confusion.
-- The way we conceptually "chunk" the browser streams may well require us to cross several semantic and syntactical boundaries.
-- We may need different tools and interfaces to create and edit the various chunks; e.g. a text editor for human content, a template editor and language for html; an editor for css, a menu tool for creating links between html pages, etc.
-- Depending upon documentation and interface design, this conceptual chunking may well impede learning, productivity, and extensibility of the system.
4. Suppose we were to use a different conceptual scheme for "chunking" the stings of characters we want to send to the browser? Could we find a way that's conceptually consistent, easier to learn, more productive, and more easily extensible?
-- A key idea here is to determine what the computer can do best vs. how the content creator thinks about, creates, and edits content and presentation.
-- In a perfect world, the computer would do all the tedious, repetitive stuff. The human content creator would focus on the intended audience and the message. This is a significant challenge for the system/tool developer.
-- Question: To what extent should the technical specialist, e.g. the web developer, stand between the content creator and final presentation?
-- I think of the web a a communication medium with a bias toward content creation and consumption so, from my point of view, the less impedance between me as content creator and my audience the better.
5. I'd suggest that we're working at three different levels when we develop tools such as Zotonic for web application development.
-- Conceptual: Here we want clarity of concept and terminology for human consumption.
-- Representational: Here we want consistent data structures appropriate for the computer language and databases we're using to implement our conceptual ideas
-- Translational: Here we're talking the language of the browser: html, css, javascript.
The process of web application tool development moves from conceptual through representational to translational; e.g.:
concept -> representation -> translation
Let me now attempt to define a specific set of terms for use at the conceptual level. If we were ever able to achieve clarity and consensus at this level then, I'd argue, technical development of web tools in whatever language would be much easier.
Keep in mind, I'm not suggesting that this set of terms is the best or most descriptive, or that we should adopt it. But I throw it out as an example of what I'm talking about. The key point is that each term in the scheme means no more nor less than its explicit definition:
content - text and images for human consumption
content element - a chunk of content as conventionally defined and understood by content creators and consumers.
-- Each content element has a type; e.g. paragraph, image, list, link and, optionally, a name or id.
-- content elements may also be paired with a style specification for presentation purposes; e.g. emphasis or consistency of graphic design.
blurb - a list of content elements. A blurb has a name, a default style, and an optional id.
-- a form or stand-alone unit of functionality, applet for lack of a better word, would also be considered a blurb.
box - a two-dimensional display or presentation of content. If the box displays a blurb, then we'd call it a container. If it contains a list of boxes, then we'd call it a wrapper.
-- boxes can be styled for size, position, and borders.
-- container boxes may have default styling for related content.
panel - synonym for wrapper.
Given this, we can say that the body of an html page is a panel that defines the page grid. Each box in the panel is assigned a blurb and a style specification. Each blurb may also be assigned a style specification
Given this vocabulary we have, I think, all the concepts and terms we need to talk about web application development system design and the tools we need to meet the needs of content creators without reference to technology.
When we start thinking about technology, however, we enter the second level of discourse: representation.
Given the programming language we chose to employ for implementation of our design, how do we best represent the concepts defined above as data structures supported by that language?
Currently, in Zotonic, we have four very different data structures: Postgresql tables, Erlang structures, html files, and css files. Javascript should also be considered here.
This, to my mind, limits us in several ways:
-- More to learn and master for fluency
-- Risks confusing our thinking and discussion about the system
-- Increases system complexity
-- Reduces opportunity of modularization
-- Makes maintenance and extensibility more difficult
-- Makes adoption of new technologies more difficult
So, back to the question. Can we do better?
Fortunately, I'd suggest, all of the concepts noted above can readily be represented as Erlang lists and tuples.
Once represented as Erlang lists and tuples, it's a fairly straight forward task to translate these structures into strings suitable for submission to the browser.
The task of translation, I'd argue, is best performed by the computer, either at the create-time or execution stage-- making it easier and less error-prone for the computer.
I can see only two possible drawbacks in this approach: It arguably makes more work for the tool developers; may result in performance penalties in production.
I'm running out of steam here, but actually have some code and am happy to explore this stuff further and share may code with any all interested.
Best to all,
Lloyd
Andreas Stenius
I'll have to pull this and check it out locally :)
2012/4/3 Marc Worrell <ma...@worrell.nl>:
Marc Worrell
There are two ways:
1. When you add a category then you should be able to define the blocks that are probably interesting for that category.
2. When you add a block then you should be able to define the categories that block is useful with.
I suspect we need them both.
But I dislike configuration, that is too tedious and repetitive.
How can we make this 'magically' work?
Maybe start with a base configuration and let Zotonic figure out how the blocks are used on a particular site?
So that you get a list of block-types used per category (and the other way around), based on what is used.
Any other ideas?
- Marc