Absolutely agree with Overmind again. Wt (Webtoolkit) is designed to
create highly interactive online web applications. Its API is
widget-centric.
Why invent another cron(8) to overload the library instead of
implementing things which will help create complex GUI fast and easy?
Regards,
Dmitriy Igrishin
2010/3/17 OvermindDL1 <[email protected]>
> On Tue, Mar 16, 2010 at 6:11 AM, Maurice Gittens
> <[email protected]> wrote:
> > Hi OvermindDL1,
> >
> > Thank you for you opinion.
> >
> > On Tue, Mar 16, 2010 at 1:08 AM, OvermindDL1 <[email protected]>
> wrote:
> >>
> >> On Mon, Mar 15, 2010 at 9:39 AM, Maurice Gittens
> >> <[email protected]> wrote:
> >> > /* snip */
> >>
> >> Quite frankly, coming from a user, WTimer should *only* be used with a
> >> session as it is the Javascript (meta-refresh?) interface, just as you
> >> would not use WText without a session (it is the <span> interface) or
> >> WTable, they are all client-side links.
> >
> > Why should it *only* be used from a session? No, sust because you say so
> is
> > not a valid technical argument.
> > I challenge you to provide properly substantiated grounds for you opinion
> on
> > this matter if you can.
>
> Er, re-read what I said, the valid technical argument is that, like
> everything else in Wt, it is an interface into a remote client
> function, which of course requires a Session.
>
>
> On Tue, Mar 16, 2010 at 6:11 AM, Maurice Gittens
> <[email protected]> wrote:
> > Please try to understand that if a WTimer requires a session to work it
> > should probably
> > be called a WSessionTimer or similar. Is that not OO design 101?
>
> Absolutely not! Do we call WText WSessionText? No, that would be
> stupid, because everything in Wt is a remote interface into a client
> side session.
>
> And that may be OO design in the Java world, but not for the smarter
> languages.
>
>
> On Tue, Mar 16, 2010 at 6:11 AM, Maurice Gittens
> <[email protected]> wrote:
> > The point is that neither the interface nor the documentation of many
> these
> > classes state anything about
> > the requirement for a session. The dependency on a session happens to be
> an
> > artifact of the current
> > *implementation*.
>
> They do not state it, because everything requires it, that is the
> *very* design of Wt. Wt is a remote gui interface, it is not local.
> We could easily make a WText that runs without a session too, what
> shall it do, print to cout, that makes sense, and it could be made
> that way, but quite frankly, just like making WTimer have a
> server-side implementation, is just plain stupid in the design.
>
>
> On Tue, Mar 16, 2010 at 6:11 AM, Maurice Gittens
> <[email protected]> wrote:
> > So when, for example, one needs to serve JSON without a session and one
> > serves stuff including strings
> > from a resource bundle should it not be supported just because you do not
> > have
> > this need? Great! Thanks for your consideration.
>
> Strings can be served without a session just fine, because those are
> stateless, but WTimer is stateful, as are things like buttons,
> listboxes, etc... Hence, they need a session.
>
>
> On Tue, Mar 16, 2010 at 6:11 AM, Maurice Gittens
> <[email protected]> wrote:
> >> If you want to work in the
> >> background, do not use Wt client interfaces. If you want a background
> >> timer, use it as your normally would, ASIO::timer or sleep or
> >> what-not.
> >>
> >
> > It helps when people recognize that there are more use-cases than their
> own.
> > What I suggest takes nothing away from your use case _and_ adds new use
> > cases
> > for other folks. Why do you oppose this? Again just because you can is
> not a
> > valid
> > technical reason.
>
> It is not 'my' usecase, it is the way Wt was designed. Wt is a remote
> interface into a client-side gui. I can oppose that because WTimer is
> a remote javascript implementation (or perhaps a meta-refresh if
> javascript is disabled), neither of those make *any* sense in the
> context of running on the server.
>
>
> On Tue, Mar 16, 2010 at 6:11 AM, Maurice Gittens
> <[email protected]> wrote:
> > Supporting new use-cases without:
> > - removing existing functionality
> > - breaking existing code
> > - significantly adding/changing existing interfaces
> > - using significantly more resources
> > - causing significant regressions
> >
> > is exactly what Wt needs.
>
> But it does make it vastly harder to maintain as you are mixing
> multiple different paradigms. WTimer is a remote interface. To do
> something locally, use a local interface, like QTimer or ASIO::timer
> or sleep/Sleep.
>
>
> On Tue, Mar 16, 2010 at 6:11 AM, Maurice Gittens
> <[email protected]> wrote:
> > Do you really think that use of Wt will grow more by reducing the number
> of
> > situations
> > in which it can be used?
>
> Not reducing anything, WTimer is perfect for the context for which it
> was created, a remote client-side interface.
>
>
> On Tue, Mar 16, 2010 at 6:11 AM, Maurice Gittens
> <[email protected]> wrote:
> > I have written enough well-used homegrown C++ application servers and I
> > personally do not
> > need Wt be improved to support more used cases.
> > But I use Wt simply because I like the idea of a open-source C++ Web
> > Application framework.
> > In fact I will probably just roll my own fast-cgi application server and
> > move on; because my code
> > is written so that it is easy to get rid of Wt.
>
> Ditto, and I have been half-tempted to because of how nasty-Java'ish
> Wt feels (and the horrible license, does not fit in with the
> Boost-style license I use for all my code), but no sense re-inventing
> things.
>
>
> On Tue, Mar 16, 2010 at 6:11 AM, Maurice Gittens
> <[email protected]> wrote:
> > But is it that hard to grasp that it is not good for the Wt user-base
> when a
> > more diverse set of
> > use-cases is not supported?
>
> Sure, but the use-case of Wt *itself* is a remote client-side
> interface. Adding functionality above that makes it harder to
> maintain, and is already quite stupid since things like ASIO (which
> comes with Wt) already includes a server-side timer. As I am sure you
> know, it is also stupid to duplicate identical functionality in a
> single project.
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> witty-interest mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/witty-interest
>
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest
