SitePoint Sponsor

User Tag List

Results 1 to 19 of 19

Thread: Wiring a DI UI

  1. #1
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Wiring a DI UI

    This is a follow on from http://www.sitepoint.com/forums/showthread.php?t=400371 but was getting OT enough imo to start a new thread.

    This is very early prototype, it doesn't actually do alot. It only works in recent Firefox versions that have SVG enabled.

    Renders each class as a svg jigsaw piece like symbol. The top sockets are the parameters the constructor takes, colour coded based on the type required. Semi circles indicate optional parameters.

    The bottom plug is what interfaces a class provides, so a single colour just means its just providing itself, multicoloured if is a subclass and/or implements interfaces.

    Can't actually wire them together yet. I'm thinking getting the bottom plug is drag'n'droppable onto a socket to create the connection.

    Thoughts?
    Attached Files Attached Files

  2. #2
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I like the jigzaw idea, but it will take some work to get it right. FoorBarImpl for example, spans two parameters (slots), so when you place it in one of the slots on FooBarFoobarImpl, it overlaps the other slots. You'll have to make FooBarFoobarImpl resize to make room. I think I prefer boxes and wires over a jigzaw, for this reason. It would also look more like UML.

    You'll have to make a visual distinction between instances and singletons too.

  3. #3
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    I like the jigzaw idea, but it will take some work to get it right. FoorBarImpl for example, spans two parameters (slots), so when you place it in one of the slots on FooBarFoobarImpl, it overlaps the other slots. You'll have to make FooBarFoobarImpl resize to make room. I think I prefer boxes and wires over a jigzaw, for this reason. It would also look more like UML.

    You'll have to make a visual distinction between instances and singletons too.
    Yeah, was thinking dragging the plug to a socket, and creating a line inbetween a successful connection (when interface requirements are met).
    Thinking retractable extension cord type thing.
    The jigsaw look is just to indicate requirements.

    Also thing there is going to be a panel on the right, with all available classes so they can be dragged onto the main graph area, like most GUI builders have.

    For singletons, not sure yet. One idea is allow multiple symbols onto the graph, therefore visually representing a new copy.
    If a single symbol is connected multiple times, then it is a singleton.
    [Though gets abit odd if one is connected multiple times, and another part of the graph has new instances.. ]

  4. #4
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ren
    For singletons, not sure yet. One idea is allow multiple symbols onto the graph, therefore visually representing a new copy.
    If a single symbol is connected multiple times, then it is a singleton.
    [Though gets abit odd if one is connected multiple times, and another part of the graph has new instances.. ]
    That wouldn't work - A class could (in theory at least) both be used as singleton and as instance. You could let the line-style (color or whatever) indicate if it's an instance or used as singleton.

    How about doing it this way instead :
    First picture shows the following (unwired) object graph:
    PHP Code:
    interface IFoo {}

    class 
    FooImpl implements IFoo {}

    class 
    Bar
    {
        function 
    __construct(IFoo $foo) {
        }

    The second picture shows a container, where Bar is explicitly connected to FooImpl.

    With this layout you won't need a separate toolbox-panel, since the interfaces are already there in the diagram. You just need a connect-as-instance and a connect-as-singleton tool.
    Attached Images Attached Images

  5. #5
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    That wouldn't work - A class could (in theory at least) both be used as singleton and as instance. You could let the line-style (color or whatever) indicate if it's an instance or used as singleton.

    How about doing it this way instead :
    First picture shows the following (unwired) object graph:
    PHP Code:
    interface IFoo {}

    class 
    FooImpl implements IFoo {}

    class 
    Bar
    {
        function 
    __construct(IFoo $foo) {
        }

    The second picture shows a container, where Bar is explicitly connected to FooImpl.

    With this layout you won't need a separate toolbox-panel, since the interfaces are already there in the diagram. You just need a connect-as-instance and a connect-as-singleton tool.
    The seperate toolbox panel is for multiple implementation of the same interface.
    For instance, a class and a mock implementation of it. In some testing setups want to use the mock, and others the class. Or for applications that define an authetication interface, and multiple implementations like PDO, POP, LDAP etc.

  6. #6
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ren
    The seperate toolbox panel is for multiple implementation of the same interface.
    For instance, a class and a mock implementation of it. In some testing setups want to use the mock, and others the class. Or for applications that define an authetication interface, and multiple implementations like PDO, POP, LDAP etc.
    Sure, but if you used the layout, I sketched above, you could have one class connect to one implementation, and another class connect to a different implementation. Each would have their own connector (line with a square end).

    Or did I misunderstand something ?

  7. #7
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    Sure, but if you used the layout, I sketched above, you could have one class connect to one implementation, and another class connect to a different implementation. Each would have their own connector (line with a square end).

    Or did I misunderstand something ?
    Like this?

    Probably going to get the lines stay horizontal and vertical, rather than a direct line as they are now.

    Also need to decided how to get the send the connection information from PHP (currently hardcoded). Might just json a lump of data.
    Attached Images Attached Images
    Attached Files Attached Files

  8. #8
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Very nice!
    I never used svg, I didn't know you could theese kind of things that easily.

    The lines would probably look a lot better if you could make bezier-curves - I believe you can do that in svg somehow ?

    Can you put a label with the variable-name on the connector, close to the square end ?

    The best way to communicate between php and js would probably be a specialized markup language. Implementing it with json would make a lot of sense, although it's important to keep it human-friendly too, since that would make it possible to write your application wiring by hand if you get fed up with click'n'drag.

    The only php<>js communication needed is the initial reflection and the final generation of the php-wiring-code. Everything in-between could be pure javascript.

    I suppose a layout-algorithm that placed elements a bit nicer would be a big plus too, although not at all essential, since you can just arrange it manually. It would be nice though if the layout could be persisted within the wire-markup.

    I figure that a dotted connection could denote a dependency (Eg. The interface needed by the constructor), while a solid line could denote a concrete registered connection (Eg. the class to use in order to satisfy the dependency). Does that make sense ?

    Sorry for the random brainstorm - make sense of it, or ignore me as you please.

  9. #9
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    Very nice!
    I never used svg, I didn't know you could theese kind of things that easily.
    Yes, its nice. Mozilla implementation is surprising me quite nicely. Was expecting to find bits not implemented.

    Quote Originally Posted by kyberfabrikken
    The lines would probably look a lot better if you could make bezier-curves - I believe you can do that in svg somehow ?
    It has bezier curves aye, and just a matter of constructing more complex path's.

    Quote Originally Posted by kyberfabrikken
    Can you put a label with the variable-name on the connector, close to the square end ?
    Yeah, will do.

    Quote Originally Posted by kyberfabrikken
    The best way to communicate between php and js would probably be a specialized markup language. Implementing it with json would make a lot of sense, although it's important to keep it human-friendly too, since that would make it possible to write your application wiring by hand if you get fed up with click'n'drag.

    The only php<>js communication needed is the initial reflection and the final generation of the php-wiring-code. Everything in-between could be pure javascript.

    I suppose a layout-algorithm that placed elements a bit nicer would be a big plus too, although not at all essential, since you can just arrange it manually. It would be nice though if the layout could be persisted within the wire-markup.
    Yes, was thinking it'll output two formats, one just wiring information for PHP consumption, the other with the layout, which could be straight SVG maybe.

    Quote Originally Posted by kyberfabrikken
    I figure that a dotted connection could denote a dependency (Eg. The interface needed by the constructor), while a solid line could denote a concrete registered connection (Eg. the class to use in order to satisfy the dependency). Does that make sense ?

    Sorry for the random brainstorm - make sense of it, or ignore me as you please.
    Yeah, have written as such can have any number of line types, using a template style mechanism. A SVG path/line is just cloneNode()'d and appended based on the id/type.

  10. #10
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ren
    Yes, was thinking it'll output two formats, one just wiring information for PHP consumption, the other with the layout, which could be straight SVG maybe.
    The layout would really just be x,y pairs of each entity. It could easily be imbedded within one format.

    I think there are three different types of persistent data ;

    Entities - Reflection data of interfaces and classes. This would be generated by PHP.
    Layout - Coords for entities (And perhaps connections). This would be generated by the wiring tool.
    Connections - The actual wiring of classes. Also generated by the wiring tool.

    The connections-part is the real product, and is what would have to be converted to PHP-code. It would also be the part which is important to make human-friendly, since you might want to write it by hand. Each part would probably have to be persistable without overriding the other. So that you can import a new reflection into an existing dataset, and thus reuse the layout + connections.

  11. #11
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Cubic Bezier curves.. :D

    One problem is with the 4 fixed attachment points, and line symbols (arrow / diamond) overlaying each other. Requires some thought.
    Attached Images Attached Images
    Attached Files Attached Files

  12. #12
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ren
    Cubic Bezier curves..
    Wow!

    Quote Originally Posted by Ren
    One problem is with the 4 fixed attachment points, and line symbols (arrow / diamond) overlaying each other. Requires some thought.
    Yeah. If there are more than one connection on one edge, that edge should have as many connection-points, evenly distributed. I think that would cover most realistic cases.

  13. #13
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Really cool stuff Ren!
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  14. #14
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    The layout would really just be x,y pairs of each entity. It could easily be imbedded within one format.

    I think there are three different types of persistent data ;

    Entities - Reflection data of interfaces and classes. This would be generated by PHP.
    Layout - Coords for entities (And perhaps connections). This would be generated by the wiring tool.
    Connections - The actual wiring of classes. Also generated by the wiring tool.

    The connections-part is the real product, and is what would have to be converted to PHP-code. It would also be the part which is important to make human-friendly, since you might want to write it by hand. Each part would probably have to be persistable without overriding the other. So that you can import a new reflection into an existing dataset, and thus reuse the layout + connections.
    Yes, there are two types of connections too.
    Implements connections are unchangeable, and therefore dont need persisting, as can be pulled from Reflection.

    Think the idea I have is to get it to load a config, guess any missing wiring, and use that as the graph sent.

    That means no additional connections are required, hopefully can get it can disconnect an existing wire by grabbing the diamond, and attach it to another implementation via drag&drop. Just need an operation then to change the connection type (instance or singleton).

    Might colour the guessed connections differently too, if there is more than one possible implementation. Once its saved, it'd be back to normal colour, as no longer needs guessing.

  15. #15
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ren
    Yes, there are two types of connections too.
    Implements connections are unchangeable, and therefore dont need persisting, as can be pulled from Reflection.
    Actually, I think there are just "new instance of class" and "get a singleton instance of class" connections. And of course an initial "not connected".
    The implements (And inherits, which we haven't had into the play yet) are structural - you wouldn't need to change thoose from the tool. The same goes for the "not connected", which shows what interface is expected.
    No need for guessing if you distinguish between expected interface (or class) and the concrete class that satisfies the expectancy. (aka the wiring)

    Quote Originally Posted by Ren
    ... by grabbing the diamond ...

  16. #16
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    <rant>
    Gah, whoever wrote/spec'd json needs a slap.
    Why can't it decode javascript toSource() created strings.
    </rant>

  17. #17
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Warning: class_implements() expects parameter 1 to be object, string given in \tests\wire.php on line 42

    Warning: Invalid argument supplied for foreach() in \tests\wire.php on line 47

  18. #18
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by REMIYA
    Warning: class_implements() expects parameter 1 to be object, string given in \tests\wire.php on line 42

    Warning: Invalid argument supplied for foreach() in \tests\wire.php on line 47
    Hmm, what PHP version?
    http://uk.php.net/class_implements
    In 5.1.0 they changed it to take a string too.

  19. #19
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The latest.
    The labels are done. Moved some svg attributes to css, cleaned up some of the js.

    Its now using information completely pulled from reflection, though the egde walking needs more work, as it draws all possible connections.

    Requires JSON extension.
    Attached Files Attached Files


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •