A downside came up to my mind just after I hit the send button: There might
be a performance issue if we add ~40 (just a approximation)
Javascirptfunctions to a browser. But I guess this is something we can only
find out by trying.
2016-02-24 10:56 GMT+01:00 Matthias Bohnstedt <matthias.bohnst...@gmail.com>
:
> Hi all,
>
> I have an interesting discussion with stefan, about some design decisions
> in the HTML UI that came in a recent patch[1]. And I would like to bring it
> up to this discus list. So feel free to join.
>
> Besides some pico mysteries, and the general discussion what should be
> manged by pico, there is one topic in particular I like to get feedback on:
>
> *Needed knowledge (very short)*
>
> Currently a Dialog is represented by a Page[2] on the Java side. Pages
> have a subset of Browserfunction (BF) [3] bounded to them. F.e. the
> SessionWizardPage (=start-session-wizard.html) are able to use the
> functions
>
> # closeSessionInvitationWizard, getValidJID, sendInvitation
>
> While the MainPage (=main-page.html = main view) is able to do use
>
> #addContact, connectAccount, disconnectAccount, deleteContact,
> getValidJID, renameContact, showAccountPage, showSessionWizard
>
> As you see we limiting the usable functions in the frontend, by giving
> each html view just a subset of he available BFs (aka BackendAPI from a
> front end designers point of view). In my opinion it's generally not
> necessary to bound them to the pages.
>
> *The idea*
> Why not make all BFs available in every page by adding them to every
> created browser instance (a IBrowser [4] is actualy the point where you add
> functions to a HTML dialog)? A frontend developer is than responsible, and
> have full freedom what functions to use. Saying this Wizard can only call
> this subset of functions and nothing else, just limits the design
> possibilities and make adding new functions to a Wizard over complicated,
> as it requires changes in the java part each time.
>
> Another pro would be, that we would decouple the BFs from the Page classes
> all at once. This dependence cause trouble if you going to implement BFs
> that uses a Page object (F.e. circle references, see commit for details).
> After such a change the BrowserCreator[5] would be the only place where
> Browserfunction needs to be present.
>
> I know the most of you are not familiar with the HTML UI, but do you see
> any downsides of this?
> What are you thoughts?
>
> Best
> Matthias
>
> PS: We have a similar situation with the renderer that are bounded to
> pages, but I will save this for another time. as this is a bit more complex.
>
> [1]http://saros-build.imp.fu-berlin.de/gerrit/#/c/3027/2
> [2]
> https://github.com/saros-project/saros/tree/master/de.fu_berlin.inf.dpp.ui/src/de/fu_berlin/inf/dpp/ui/webpages
> [3]
> https://github.com/saros-project/saros/tree/master/de.fu_berlin.inf.dpp.ui/src/de/fu_berlin/inf/dpp/ui/browser_functions
> [4]
> https://github.com/ag-se/swt-browser-improved/blob/master/src/main/java/de/fu_berlin/inf/ag_se/browser/IBrowser.java
> [5]
> https://github.com/saros-project/saros/blob/master/de.fu_berlin.inf.dpp.ui/src/de/fu_berlin/inf/dpp/ui/ide_embedding/BrowserCreator.java
>
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
DPP-Devel mailing list
DPP-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel
