[
https://issues.apache.org/jira/browse/LABS-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784290#action_12784290
]
Simone Gianni commented on LABS-494:
------------------------------------
There is another approach we are experimenting, forced by the pressing demand
of visual programmers wanting to customize heavily.
Since now the lists and bean output and forms are generated from a velocity
file, which is cached for better performances, nothing is preventing from :
- Writing your own velocity file
- Writing your own velocity snippet for a single field
This has been done using custom aspects on a project we are working on, but
could be incorporated in Magma provided we find a good way for standardizing
it. The target is having visual programmer customize stuff without requiring
modification on the java side, so a convention over configuration (a certain
file in a certain path) OR the dynamic configuration implemented for LABS-365.
The advantage of using dynamic configuration are :
- configuring a specific situation or a generic one (like that field in that
situation, that field always, etc..)
- overriding pre-existing configurations
- unification
The disadvantages are :
- need to specify a file, so a complete path?
... a complete path, or using some placeholders, like {beanclass} or similar
- need to learn the syntax of the configuration
- would be an extension of the current late configuration system, cause it by
default calls setters
... or they could be setters on the style, but the syntax would be cumbersome,
like "User.customDisplay=name,/path/to/my/name.vm" to call
BeanStyle.customDisplay(String field, String path).
- how to cache it?
... if they are setters, we can cache it based on what setters are called
... moreover, if they are setters, they could be converted to aspects later
The advantage of using convention over configuration are :
- create the file, and that's it
The disadvantages are :
- need to rethink current conventions
... for example, each handler should have a folder to contain specifically
named files
... must provide a convention for the two biggest cases (that field in that
situation, that field always)
- cannot specify the context in the same flexible way
... How to specify that I want that format only on that list, and that other in
that show bean, given they are both returned by the same handler?
- how to cache it?
... since the cache id must be calculated before actual execution, we'll end
polling for the presence of the file all the time
- need to learn a naming convention
... which will not be reused, as opposed to learning the configuration system
which is used in many more situations
> [web] More support for CSS styling
> ----------------------------------
>
> Key: LABS-494
> URL: https://issues.apache.org/jira/browse/LABS-494
> Project: Labs
> Issue Type: Improvement
> Components: Magma
> Affects Versions: Current
> Reporter: Simone Gianni
> Assignee: Simone Gianni
> Fix For: Current
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> Currently Magma offers a flexible way to aggregate output from different
> methods in the page. Howeverm, since the HTML is often generated by Magma
> components, great care is needed in offering enough HTML elements and CSS
> classes to permit a complete CSS customization.
> Currently, most components (like lists and forms) do provide extensive CSS
> classes. The template and compunding system however don't.
> When a template is outputting different parts in a zone (like for example
> boxes) it wraps those pieces in divs, but which CSS classes are applied to
> that div is not clear.
> At the same time, for I18N and other systems, Magma keeps a kind of "stack"
> of the context in which it is evaluating current HTML, making this
> information available on the page CSS seems to be a simple and complete way
> of having all the informations.
> So, each time the template is producing an HTML div around an HTML piece, it
> should include all the non-already-outputted context as CSS classes, plus a
> "relation class", which will always be the same.
> Moreover, whenever the compunding system outputs a compunded piece of HTML,
> it should wrap it in a div, placing again the context as CSS classes, plus a
> relation class that indicates the kind of compound.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscr...@labs.apache.org
For additional commands, e-mail: labs-h...@labs.apache.org
