voytech / cljs-diagrams Goto Github PK

Event name should be extendend by optional component identified by 'i' denoting that this particular behaviour is registered for entity single instance rather than for all entites of type

Cannot make endpoint connectors to reflect index 999 properly (to be always on top.)

Implement behaviours as extension methods registering handlers on event bus. Add prerequisities for extension assignment

There will be helper macro defbehaviour which adds a new behaviour to registry and registers handler to eventbus when requested. Behaviour will be installed for specific component name or names. Potentially could be automatically registered on eventbus when it is decided to do so.

defbehaviour can be e.g. defined to execute on specific event but be activated only when specific entity properties are met.
Example condition may be: if an entity is composed of several specific components that means it has a property that should be handled by specific behaviour - so trigger activation of behaviour for specific entity on bus.

An algorithm for that must be invented.

DSL should be much more intuitive than it is now. E.g. It should be possible not only to reuse existing designer components within entities and attributes, but also You should be able to define new attributes, components within defentity macro. Code is less scattered then.

Implement layout abstraction to allow different approaches to position elements. Same layouting mechanisms should be used for different containers :

• for attribute container ( entity )
• for entity container (project canvas, root entities)
• for component layer ? ( construct not yet exists - just thinking of it )

Common properties of layouts :

• layout name
• layouting function
• layout instance properties:
  • origin(x,y) - starting point of transforms relative to container. Origin can be : center , corner.
  • left or right - relative position from origin (pixels or percents)
  • top or bottom - relative position from origin (pixels or percents)
  • width, height (pixels or percents - if percents then its relative to container sizing.
  • direction - left-to-right, right-to-left, top-to-bottom, bottom-to-top.
  • overflow - extend, hide.

Move all specific entity behaviours related to particular entities into corresponding impl modules.

Move following functions:

insert-breakpoint
dissoc-breakpoint
position-breakpoint
position-endpoint
position-startpoint

Create new simplified frontend using Reagent.

Generalize entity behaviours functions and merge with core behaviours.
Move following functions:

1. position-drawable -> default-position-drawable
2. position-entity -> default-position-entity
3. apply-effective-position
4. calc-effective-position
5. effective-position

for default-position-entity:

1. Add possibility to pass overrides as follows :
   1.1 Positioning drawables overrides :
   {:relation position-relation :endpoint endpoint-position :startpoint startpoint-position}
   1.2 Postitioning related entities overrides:
   1.3 Positioning attribute overrides.

Overrides could be potentialy injected automagically when implementation for specific component type is found in registry.

Namespace qualified entity type, component type , drawable type keywords. Currently we have entity Type as string - should be namespace qualified keyword. Same for component Type and drawable type. Reason for that is to remove possibility of unintended overriding of these elements.

Implement manhattan layout

Attributes will alllow to provide data to entitites.
Attribute should contain name, and a type which will drive its behaviour and rendering.
AttributeValue will be instance of given attribute, will contain reference to attribute definition and will be directly linked to entities.

Relationships between entities should not only be directed as currently.
Instead of specific relation direction pass and then iterpret relation context in form :
{ :relation-type :association-data}

e.g. :
{:relation-type :uni_direction :association-data :end}

{:relation-type :aggregate :association-data :parent}
{:relation-type :aggregate :association-data :child}

then - function connect-entities - will look like this :

1. connect-entities[e1 e2 type args1 args2] - effectively creates two relationships maps :

• {:relation-type :type :association-data :args1} - added to e1 relationships coll.
• {:relation-type :type :association-data :args2} - added to e2 relationships coll.

2. connect-entities[e1 e2 type] - effectively creates one relationship and adds it to both entities.

where:
e1 - first entity
e2 - second entity
type - relation type
args{1|2} - association data for given entity

As new layouting mechanisms will be implementend there is no point for keeping entity property : content-bounding-box which was used for layout boundaries for attributes. Instead of this there will be additional with-attributes argument - a var to layout instance or var to layout def and contex data for instantiation.

Fix performance issues. Periodic hangs and probably leaks after some period of time.

It is most visible on firefox.

Library should consist of following items:

1. Photos - uploaded using FileAPI.
2. Toolbox - It would be great it it is possible to iterate through all fabric.js provided items and create
   basic tool for each.
3. Templates - templates are canvas with corresponding entities.

Should use dnd to place above items on canvas..

Sometimes control handles attached to lines on relation entity are detaching.

Two entities should be connected by relation

• when one entity is dropped so that it intesects other entity
• when both entities are eligible for relation

Name attribute should consist of: text component, rect component

Remove attribute order property and include as a property to default-layout-properties. Add layout-properties to AttributeValue with mandatory dynamic index attribute (populated when new attribute added)

Instead of separate drawable records (which unneceserilly introduces aditional level of complexity) introduce 'render-method' field i to component records.

Component wraps drawable but is not directly related to rendering. It Adds some hints and properies for specific component type which can be used in relation to other components under specific entity

Generators should be generic tool related components which will allow to build complex tool components (event templates will be implemented via generators).
Generator characteristics:

• can be bound to tool.
• when bound to tool - generator will build tool associated entitties in predefined set of steps declared as generator transformation functions.
• there will be predefined generators as well as generatros defined by user (via Tool Creator).

relation drawable incorrectly sets bounding box!

When trying to connect two entities mnhattan layout doesnt draw lines correctly

Relation entity attribute flow layout should have sophisticated layouting context initialization function. This function should setup cursor starting position to the origin of middle line component from relation entity.

defbehaviour should be more flexible and expressive.
defbehaviour should be defined as follows:
pseudo code : (having-all | having-strict | having-some input-types attach-to targets resolve-to (fn [target]))

having-all - all input-types must be present in test input
having-strict - input-types set must be equal to test input
attach-to - vector of target component on which to attach behaviour
resolve-to - having input evaluation target return event name.

• Drawable should be an interface for abstracting canvas2d context operations.
• Should contain drawable object properties as long as drawable type which can dispatch to specific renderer. Drawable holds RenderingState which can be any data supporting rendering depending on specific renderer implementation.

Get rid of mouse events names. Switch to component name

DomainEditor should operate on attribute values of attribute with domain of values. Will be implemented as select element.

Add project state which will be passed to events. This state can be used to model entity and entity group selections and so on.

This is going to be large architectural change.
Before starting this task create tag for existing version.

Current problems:

• All project data is global and scattered in various namespaces
• You can access data which should be private (this can be changed but it can be also completely eliminated)
• Modifictions of entities and other application data records is error prone - due to nature of clojure data structures - modification of entity record structure directly (not on atom entity map) produces new entity.
• Sometimes I'am still using old entity reference while I should either modify entity map or perform new modification on entity fetched from map. Above constraints and a need to remember them when implementing new behaviours made me convinced that this mutability is wrong here.

Solution proposition

• get rid of global mutable data.
• pass project record as an argument to main initialization entry function.
• pass project data record to all module functions to obtain project context.
• change all API functions (component API, entity API) to take as a first arg - project record + other arguments. Also make them return map of {:project :result }.
• all API functions should perform project-data modifications and do not allow project-data managed records modification decoupled from entire project-data context (should not allow modification of single entity record, but should modify it directly on project-data atom structure).
• event bus should be a also passed to initialization function and project data should be injected into event-bus initialization function so that "make-event" function can add project-data into each event.

Effectively initialization function should be single entry point for a library with some initial project-data atom and calls to other modules initialization functions (event-bus, events, so-on).

Add drawable z-index

Unify entity , component and drawable api to reduce or even eliminate direct nested property accesses.

Eliminate:
(map Fn (:components entity)) and so on ...

Attribute validator for decision making about entity <-> attribute compatibility.

Implement svg renderer.

Attribute selector behaviour for adding new attribute values to entites.

Remove behaviour action property and include it as behaviour validator's resulting event name part.

Implement webapp with following functionalities:

• project canvas with sample tools
• sample attributes
• possibility to switch renderers. (after implementing svg renderer)
• possibility to upload own behaviout, attribute and entities !
• debug dialog.

Do not mix canvas with html5 canvas.
Canvas will be a manager of entities and attributes which are being modeled.

add-entity
remove-entity
bind-attribute
remove-attribute
do-layout
set-view-bounds
zoom-in
zoom-out
copy
paste
undo
redo.

Above functions shows desired functionality.

Move drawable record state property to rendering.cljs to separate map. Separation of concerns

Implement behaviour for attribute text editing.
After dbclick on attribute popup-like input tag will be rendered overlaying entity. This input will hold temporary state of an attribute, after commiting, attribute data will be synchronised down to components and drawables.

Components should not only be an instances. Should have definitions which Will allow reuse.

Component def:

• factory function which takes data and returns instance.
• drawable function reference
• type
• props
• initial-data

Needs to be able to lookup component def by type