Jeff AA writes: > Sounds interesting, can you briefly describe the MVCF parts, and what > their responsibilities are?
http://www.bivio.biz/hm/why-bOP contains a decent explanation of how we think about MVC. There's also a talk with notes: http://www.bivio.biz/hm/csci7818-bop-intro/intro > Have you split the View into View + Facade? Views and the Controller request values from the Facade configured for the incoming request or command line function. Models don't really need to talk to the Facade, since Models should be purely internal and the Facade is about user interface elements. Models do manipulate the HTTP form values (which are not UI elements imo) and query strings (which are part of the UI, but we don't map query keys via the Facade). A couple of people have mentioned the concept of a "container". We call this concept Attributes: http://petshop.bivio.biz/src?s=Bivio::Collection::Attributes MVC components are derived from attributes. A Task has attributes (name, number, permissions, items to execute, next). A View has attributes (parent, variables). Widgets are configured with attributes (cell_bgcolor, string_font, etc.). Models have attributes (fields). A Request has attributes (path_info, port, auth_user, etc.). Attributes proved to be a significant breakthrough in the simplification of the interfaces. The views and widgets don't know about models for the most part. They can just as easily format the incoming server name from the request and the user's name from a model. And you can flow seamlessly between them, e.g. ['auth_user', 'name'] This widget value is the name attribute from the model identified by the request's auth_user attribute. Facade components are bit different, because their values are often hierarchical and grouped, e.g. you want to group the namespace of the "alt" tags for icons separately from other in spaces: $fc->group(Image_alt => [ dot => '', goback => 'Back', continue => 'Continue', ]); or you want to group a bunch of symbolic font names to a single font specification: $fc->group([qw( strong bold table_row_title )] => ['bold']); You also want to be able to manipulate these values in clones and children of facades. The Attributes class is a simple one to one mapping.. However, FacadeComponents do support the WidgetValueSource interface which means Font values can be accessed by Widgets just like other MVC components. > What are the differences between your MVCF and the MVP pattern? I didn't know what the MVP pattern was. I don't think the MVP pattern is applicable to Web interfaces. GUIs are fundamentally different from HTTP. HTTP is stateless, screen-oriented, and client-server. One of the reasons why Perl is so well suited to the Web is that you don't need asynchrony (threads) and you do need to manipulate lots of strings. The Web is a "transformational" system. GUIs are interactive systems. > > URLs are part of your user interface, not your controller. > I think I like this, though the w3 might not 8-) The W3C is dreaming if they think there ever going to get rid of people typing in Web addresses. Even if they somehow magically get rid of them, people will still bookmark them. This means you need multiple URL mappings to the same operation for backwards compatibility. We have rearranged our site URLs several times, but we kept the old mappings. The URLs for the entire site are contained in a single file. A Task can have multiple mappings, but always has a single primary URL. > I find that the mix of business object e.g. Bank Account and > presentation objects, e.g. Table can lead to confusion - are your Table > objects just a way of organising data, or do they contain presentation > style hints -e.g. dynamic width indication etc? Table is a Widget. BankAccount is a Model. > Do you have something similar to a Bank Account object with some primary > properties and containing a collection of current Transaction > objects? There are no transaction objects. You can push transaction resources on the request and if the Task completes successfully, they will be committed. > Or do you focus on the presentation style objects - Tables, nested > Tables, Lists etc? We do the whole thing. Config, tracing, alerts, OR mapping, command line abstraction, etc. It's the same thing you having just about every modern OLTP system. We looked back pretty far to get where we are now. :-) > I looked over your site and code, compact and impressive - probably a > stupid question, but are there any higher-level overviews of your > approach / framework? There isn't more documentation except for the classes themselves. The best way is to download bOP and start twiddling with it. Thanks, btw. Our goal is compactness, but not in the sendmail.cf sense. :-) It's certainly not everybody's cup of tea. For a microview of the declarative style, checkout: http://petshop.bivio.biz/src?s=Bivio::XML::DocBook which dovetails with the XML discussion. ;-) Rob
