http://skrishnamachari.wordpress.com/2012/01/31/pharo-application-framework-aka-morphic-view-framework/
Obliged for feedback ... For details and links.. Sharing this little framework that should go some way to ease creating large applications ( currently morphic oriented). AbstractMorphicView subclass: #MyNewView … #createMorphsSpecs ^{ ‘panel1′ -> #SomeOtherView. layoutSpecsArray ^{ “… add other widgetspecs…” Thats it.. you should have a prototype UI neatly laid out.. and then specify: #morphsPrimaryPropertiesSpecs and #morphsSecondaryPropertiesSpecs for full functionality that composes views inside views and scales well. AbstractSimpleMorphicView can make it simpler for TableLayout stuff without requiring #layoutSpecsArray. ..... the main post has other details and links to package... |
did you see what benjamin is doing with Spec.
Because you should join effort the idea is that we can define object with spec and compose them and their logic using value holder. Stef On Jan 31, 2012, at 5:58 AM, S Krish wrote: > http://skrishnamachari.wordpress.com/2012/01/31/pharo-application-framework-aka-morphic-view-framework/ > > Obliged for feedback ... > > For details and links.. > Sharing this little framework that should go some way to ease creating large applications ( currently morphic oriented). > > AbstractMorphicView subclass: #MyNewView … > > #createMorphsSpecs > > ^{ > > ‘panel1′ -> #SomeOtherView. > ‘label1′ -> #LabelMorph. > ‘text1′ -> #PluggableTextMorph. > ‘button1′ -> #PluggableButtonMorph. > } > > layoutSpecsArray > > ^{ > ‘widgetNameInMorphsDictionary’ -> { > #fractions -> (0 @ 0 corner: 1 @ 0.5). ” fractional value 0 to 1 range ” > #offsets -> (10 @ 10 corner: 0 @ 0). ” offsets relative to the fractional position ” > }. > > “… add other widgetspecs…” > } > > Thats it.. you should have a prototype UI neatly laid out.. and then specify: #morphsPrimaryPropertiesSpecs and #morphsSecondaryPropertiesSpecs for full functionality that composes views inside views and scales well. > > AbstractSimpleMorphicView can make it simpler for TableLayout stuff without requiring #layoutSpecsArray. > > ..... the main post has other details and links to package... > Spec.pdf (531K) Download Attachment |
Sure I will review this pdf.. and come back on this..how well should
integrate the specs part.. The framework though is based on the spec and extensibly on direct composition and does a little more towards building a scalable/ flexible framework that incorporates in one simpler hierarchy all that goes into a standard large application creation.. How is the Presenty work supposed to work along with this..? On 1/31/12, Stéphane Ducasse <[hidden email]> wrote: > did you see what benjamin is doing with Spec. > Because you should join effort > > |
2012/1/31 S Krish <[hidden email]> Sure I will review this pdf.. and come back on this..how well should For Presenty Specs can be used for code presentation of concrete morphs (view prototypes). If Specs can save arbitraty morph to method I will use it. And Presenty will got monticello support. |
In reply to this post by S Krish
On Jan 31, 2012, at 1:23 PM, S Krish wrote: > Sure I will review this pdf.. and come back on this..how well should > integrate the specs part.. but Spec is a spec based UI builder. > The framework though is based on the spec and extensibly on direct > composition and does a little more towards building a scalable/ > flexible framework that incorporates in one simpler hierarchy all that > goes into a standard large application creation.. Ok but did you ***read*** what benjamin said: he iterated on it and now it is a good basis to build support for a lot of widgets. Have a look at his document. It would be good to avoid to have several frameworks doing the same. For example I would like to have more tests. The prototype part is open. We did not think much about it. > > How is the Presenty work supposed to work along with this..? > > > On 1/31/12, Stéphane Ducasse <[hidden email]> wrote: >> did you see what benjamin is doing with Spec. >> Because you should join effort >> >> > |
In reply to this post by Denis Kudriashov
On Jan 31, 2012, at 3:04 PM, Denis Kudriashov wrote: > 2012/1/31 S Krish <[hidden email]> > Sure I will review this pdf.. and come back on this..how well should > integrate the specs part.. > > The framework though is based on the spec and extensibly on direct > composition and does a little more towards building a scalable/ > flexible framework that incorporates in one simpler hierarchy all that > goes into a standard large application creation.. > > How is the Presenty work supposed to work along with this..? > > > For Presenty Specs can be used for code presentation of concrete morphs (view prototypes). > If Specs can save arbitraty morph to method I will use it. > And Presenty will got monticello support. Denis we do not want to rely on saving a Morph to a method (serialization). Now it does not mean that we cannot use the prototype idea. We could have a spec that creates an object used as a prototype for building UI. Saving a prototypes and building interface are orthogonal. Stef |
2012/1/31 Stéphane Ducasse <[hidden email]>
Yes, I understand this |
In reply to this post by S Krish
If you have around the pdf you are talking about on your website, I will be glad to read it.
Thanks in advance ;) Ben On Jan 31, 2012, at 5:58 AM, S Krish wrote: http://skrishnamachari.wordpress.com/2012/01/31/pharo-application-framework-aka-morphic-view-framework/ |
I will provide this by the weekend
The code though has tests which are quite explanatory and the classside method of the ApplicationFrameworkdDocumentation has 6 odd methods that lead on from intent, what Pharo provides which maybe leveraged in future if not now and the current implementation as well as a roadmap.
I will read your specs and implementation to merge the stuff I envisage with
On Wed, Feb 1, 2012 at 5:14 AM, Benjamin <[hidden email]> wrote:
|
I read your code but I can't understand why there are so many classes to provide such an API.
Ben
2012/2/1 S Krish <[hidden email]> I will provide this by the weekend |
Primarily for the view spec framework if I want it purely segregated
it would only require the AbstractMorphicView class and can work absolutely independent of the rest of the classes you see, with removing the initializations for MorphicEventHandler/ MorphicMouseHandler in the accessors. ****************** Will provide a doc / little better explanation by weekend. Immediate answer is, this is just not for Morphic View but adds up other capabilities as I mentioned intrinsically to a created application, including: * Configuration based constants, Logging, Translation, mouse/ keyboard handlers on a view level, NamedPrototype and a common Object class for such apps in PharoMorphicObject * subclass a basic MorphicViewController to add a SupervisingController capability as per MVP explanation by Martin Fowler. * MorphicViewEventHandler and MorphicViewMouseHandler are for default keyboard shortcuts and mouse handling at the view level over and above per widget. many of these capabilities I am wanting the framework to posses, is standard for any small/medium/large enterprise application to have. I do see your point though .. a package segregation can be done with probably just one or two classes for the basic view framework and then add packages that have incremental needs fulfilled can be done to reduce fortitous complexity up front. On 2/1/12, Benjamin Van Ryseghem <[hidden email]> wrote: > I read your code but I can't understand why there are so many classes to > provide such an API. > > > Ben > > 2012/2/1 S Krish <[hidden email]> > >> I will provide this by the weekend >> >> The code though has tests which are quite explanatory and the classside >> method of the ApplicationFrameworkdDocumentation has 6 odd methods that >> lead on from intent, what Pharo provides which maybe leveraged in future >> if >> not now and the current implementation as well as a roadmap. >> >> I will read your specs and implementation to merge the stuff I envisage >> with >> >> >> On Wed, Feb 1, 2012 at 5:14 AM, Benjamin < >> [hidden email]> wrote: >> >>> If you have around the pdf you are talking about on your website, I will >>> be glad to read it. >>> >>> >>> Thanks in advance ;) >>> >>> Ben >>> >>> On Jan 31, 2012, at 5:58 AM, S Krish wrote: >>> >>> >>> http://skrishnamachari.wordpress.com/2012/01/31/pharo-application-framework-aka-morphic-view-framework/ >>> >>> Obliged for feedback ... >>> >>> For details and links.. >>> >>> Sharing this little framework that should go some way to ease creating >>> large applications ( currently morphic oriented). >>> >>> AbstractMorphicView subclass: #MyNewView … >>> >>> #createMorphsSpecs >>> >>> ^{ >>> >>> ‘panel1′ -> #SomeOtherView. >>> ‘label1′ -> #LabelMorph. >>> ‘text1′ -> #PluggableTextMorph. >>> ‘button1′ -> #PluggableButtonMorph. >>> } >>> >>> layoutSpecsArray >>> >>> ^{ >>> ‘widgetNameInMorphsDictionary’ -> { >>> #fractions -> (0 @ 0 corner: 1 @ 0.5). ” fractional value 0 to 1 range ” >>> #offsets -> (10 @ 10 corner: 0 @ 0). ” offsets relative to the fractional >>> position ” >>> }. >>> >>> “… add other widgetspecs…” >>> } >>> >>> Thats it.. you should have a prototype UI neatly laid out.. and then >>> specify: #morphsPrimaryPropertiesSpecs and >>> #morphsSecondaryPropertiesSpecs >>> for full functionality that composes views inside views and scales well. >>> >>> AbstractSimpleMorphicView can make it simpler for TableLayout stuff >>> without requiring #layoutSpecsArray. >>> >>> ..... the main post has other details and links to package... >>> >>> >>> >> > |
In reply to this post by S Krish
The PDF documentation of the framework. Obliged for review/ read and comment and try out the first release..
Ben, I have done a first read of the Spec and I will get my head around how this should be converge.. Will work on that.
Though I must note that the spec framework I have laid out is simplistic, flexible and uses the current framework of classes/ morphs without the ValueModel wrapper. Perhaps there is a common ground there, but I would like to emphasize on flexibility of spec and explicit construction to mix and built out has been central to the thought process. On Tue, Jan 31, 2012 at 10:28 AM, S Krish <[hidden email]> wrote: http://skrishnamachari.wordpress.com/2012/01/31/pharo-application-framework-aka-morphic-view-framework/ PharoMorphicView.pdf (796K) Download Attachment |
Free forum by Nabble | Edit this page |