ROWS, COLS & TABS als alternatieven voor BOX
Brought to you by:
han_joosten,
oblosys
Menu
▾
▴
#452 ROWS, COLS & TABS als alternatieven voor BOX
closed
None
fixed
ADL scanner/parser
normal
feature request
2015-02-18
2015-01-06
No
Naast de onlangs toegevoegde ROWS en COLS (als synoniemen voor BOX in de interface specificaties) zouden we ook graag TABS toegevoegd zien. In de vernieuwde frontend applicatie waar ik mee bezig ben kunnen we deze form van representatie al weergeven.
Op korte termijn is de bedoeling om vanuit de interface specificaties HTML templates en MVC controllers voor het Angular framework te kunnen genereren. De toevoeging van TABS loopt hierop vooruit.
The information about TABS, ROWS and COLS must be inserted in the F-structure, so that the code generator can pick it up.
Michiel, the following step will be to allow MATRIX. However, I wonder if just adding the word MATRIX to the syntax will yield enough information in the frontend to build a matrix. What do you think?
Stef, what kind of presentation would you expect with MATRIX?? Can you get the required data with the current BOX [] statements?
Stef, zoiets: http://bost.ocks.org/mike/miserables/
Groeten,
Michiel
It seems that the new frontend is very inspiring and causes lots of new ideas to be proposed that have to deal with the presentation of stuff in a UI. Very good!
However, we are now also starting on a road where every cool idea requires changes to the parser and the F-structure (and what else...). This seems a bit too cumbersome for the long run.
I would like to see a way where keywords that are required for the UI (such as COLS, ROWS, ...) can be used in an INTERFACE specification without the necessity to change the parser and F-structure all the time.
The traditional syntax has been
We have been asking for:
Martijn and Michiel are currenly looking into how these structures have to be coded into the HTML-pages that the prototype is going to generate for the new front end. They have agreed to do this first in a straightforward manner, so that with this experience they can come up with a more generic way to add structures such as
that Stef is asking for. What we will need is something that supports the syntax
where <IFCX> can be any (upper case) characterstring. For every instance of <IFCX>, you can create a file (or two) that specifies how the associated HTML stuff must be generated. Then, for every such instance ampersand.exe would test for the existence of such specs and generate the associated HTML, or return an error if such specs do not exist.
I agree with Rieks. Moreover I would suggest to make a distinction between interface specifications and its related user interface (UI) specification. Currently these are combined in the INTERFACE specification in &.
In my opinion, the interface specification should be about how the data is provided (tree structure) and which userrole can read, update, create and delete data (CRUD). No all the expressions that exists in an interface specification determine that the related data can be read and the relations that are mentioned between the parentheses () can be edited (i.e. updated). This only covers part of the CRUD operations possible. It it also allowed to create a new Atom of a certain type, how about deleting not only the relation (current behavior) but also the tgtAtom itself?
An UI specification should be about how the data is presented to the user. This should be the place for structures like ROWS, COLS, TABS and MATRICES. But why not be able to use, for example, XSLT stylesheets?
Interfaces are about transforming one CONTEXT into another CONTEXT. The statements in an interface definition ("<some text="">" : exp) transform the ampersand model (CONTEXT 1) into human readable term (CONTEXT 2). Likewise we could transform an ampersand model into a specific XML representation using "<ns:element>" : exp. This illustrates that interfaces are not always about user representations.
Maybe we could look into a separation of concerns, before major restructuring the INTERFACE specification, e.g.
CONTEXT "A to B"
INTERFACE "some interface" : I[Concept]
BOX [ "abc" : exp1 [CRUD]
, "xyz" : exp2 [R] INTERFACE "another interface"
]
UI FOR "some interface" : exp[SESSION*TEMPLATE] // expression that determines which template to use.
ROLE FOR "some interface" : role1, role2, etc
ENDCONTEXT
I'am not yet convinced that this should be the way to go as there are still many open questions. E.g. how can we then generate templates based on the interface definitions, if we don't have structures like ROWS, COLS, etc anymore. Maybe a combination with the feature request in the above post, but then again, mixing UI with interface definitons.
What do you think?
I'm not sure I completely understand how interfaces are about transforming contexts. I see them more as a way to specify the kind of queries we allow for an external agent to inspect/update the data from a certain context. However, this does not seem to affect the discussion here all that much.
My idea for handling different presentations of interfaces would be to use a class model, similar to html classes. Because all proposed extensions (except possibly MATRIX) are different flavors of BOX, the most straightforward extension to the model is to parameterize a BOX with a class field. We could even have a simple syntactic extension to specify such classes, e.g. BOX<TABS> or BOX<CONTEXTMENU>. The class is an optional string that is used to generate specific prototype code. Simply allowing any keyword to be used instead of BOX as suggested above is in my opinion not a good idea, as it will make it impossible to have other keywords like INTERFACE (unless we make those a special case, but that clutters the parser.)
Michiel's suggestion to completely decouple the presentation/UI specification from the interface may or may not be a good idea but it is currently unclear to me what this would look like. To prevent creating abstractions for patterns we are not yet familiar with (and possibly making the construction of simple examples more complicated,) we could work with the class system for now, and extend it when we have a better idea of what we want.
Related is the discussion of primitive concepts. I think there are two orthogonal issues here: support for primitive concepts (BOOL, NUMBER, etc.), and support for specialized presentations of concepts. For example, a BOOL could be presented as a checkbox but also as a textual string. We can probably also use the class system for this. In addition, we may even be able to express VIEWs this way, as they are not that dissimilar from interfaces.
I wholeheartedly agree. Let's start with the BOX-CLASSes system. Let's see if we can make it work for (the presentation of) primitive concepts equally well as for the other concepts, which would eventually make 'VIEW' obsolete. Rieks
Last edit: Martijn Schrage 2015-02-09
Hi Martijn,
I agree with you. Let's go for the classes system BOX<class> for now. I saw that you implemented the Atomic-<CONCEPT> templates system. That is very powerful. I just introduced a template for Atomic-PASSWORD, which behaves like a HTML5 password input field. Great!
Could we do the same for the BOXes?
I also have a reaction to the primitive datatypes discussion, but posted it in corresponding ticket #456
Michiel
The box syntax now allows
BOX<Class>.