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 <stephane.ducasse@inria.fr> wrote:

did you see what benjamin is doing with Spec. Because you should join effort

On Jan 31, 2012, at 3:04 PM, Denis Kudriashov wrote:

2012/1/31 S Krish <krishnamachari.sudhakar@gmail.com> 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

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 <stephane.ducasse@inria.fr> wrote:

...

did you see what benjamin is doing with Spec. Because you should join effort

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...

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...