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 <benjamin.vanryseghem.pharo@gmail.com> 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 <krishnamachari.sudhakar@gmail.com>
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 < benjamin.vanryseghem.pharo@gmail.com> 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-...
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...