Hello Sebastian,
> to make the app consise for desktop *and* mobile devices is really a
> challenge. I can't think in that withou remaking to adapt almost all
> components to those little screens in mobile devices. The domain model will
> be 100% shared the presentation domain will be near zero and is the is the
> most heavy cost this days
I fully agree - except for one core subject:
I have always (> 20 years) been a firm believer in "data beats code" and this is why we have always defined most of the UI in data. This is how we re-use the desktop forms from VW for Seaside (not all but many). The same data (form definitions) is just generated in a different form in HTML. (BTW: Most unfortunately this principle has not been adopted for the new VW UI, a great great mistake in my eyes).
We use this same way for defining nested views / forms and menus in data. Even our models are all defined this way: A descriptor instance for every attribute, NEVER any hardcoded instance variabnles. That is evil in my eyes. It's all in data and therefore also highly version dependent. For convenience we generate this "data" currently from static, version dependent methods as we have no better administration system altough larger data definitions are first created in Excel (nothing is faster) and then filed into code. But in the compiled run-time image it's all data - and that can even be loaded from ASCII files so that a user admin can modify the layout.
Having it all in data is the prerequisite in my view.
And this is also mandatory to avoid this great great and extremely bad Anglo-Saxon system (and mistake) of including language into code. This always annoys me as our customers are not willing to adopt English and because I always feel raped. Even error notes MUST be in a library. Including this in English into the code is very, very bad and extremely ignorant in my eyes. The world is multi-lingual and therefore in our system all language related stuff is represented by symbols, which are also easier to find, and traslated at run-tim from an external library (modifiable by the user), which can even be switched dynamically.
> does not imply an entire rebuild of the presentation domain
Relatively simple data structures fulfill this, I think. They are used to generate what one needs. We should not forget that generating code from data is as simple in Smalltalk as probably in no other language (except some few exotics).
Beyond this, such a mobile project as a stand-alone one would not be of much interest for us unless part of a more comprehensive solution together with an IM, with an email client referring to text conserves and with an VoIP system.
However, I would be very interested in sharing this entire project with some partners and we would be ready to contributed our system. Please understand that we would never give up these principles and go back to the ancient "text in code" principle. Impossible!
Best regards
Frank
_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Locked
