[Seaside-dev] JQuery tests and flow

Fri Nov 20 07:14:54 UTC 2009

Yes, my reply (and yours) should have gone to the list...

If we go this route, it should definitely be BasicDevelopment, not
Basic-Development (unless there are going to be other "Basic" things)
but the distinction seems kind of arbitrary to me. It's hard to see
what makes the walkback handler "advanced".

As I said in my last message, I'm not totally convinced but I don't
feel that strongly so if you're keen and nobody else objects then
let's just sort out naming and move forward.

Julian

On Thu, Nov 19, 2009 at 7:42 PM, Dale Henrichs
<dale.henrichs at gemstone.com> wrote:
> I was thinking of creating a package like Seaside-Basic-Development to hold the guys that don't require flow (the bulk of Seaside-Development) then only changing the handful of packages that are flow-free to be dependent upon Seaside-Basic-Development ... that way the exception would be to get things without flow (the uncommon case) and anyone already used to clicking on Seaside-Development (in build.seaside.st) would continue to do so without surprises...
>
> Getting the partitioning carved up into useful chunks (relative to unnecessary dependencies) is probably a good thing ... build.seaside.st providing defaults and visual feedback for dependencies (or groups defined in Metacello) takes most of the mystery out of what to load...
>
> With that said, I'm interested in the opinions of others as well..but this ended up being private email:) - if you want I can forward my reply to the list...
>
> Dale
> ----- "Julian Fitzell" <jfitzell at gmail.com> wrote:
>
> | My guess is that the other three senders can be replaced if desired
> | with #show:onAnswer: (or just #show:).
> |
> | The error handler is the big doozie - it definitely needs
> | continuations.
> |
> | I would say that splitting is logical, it's just a tradeoff against
> | usability when there are too many packages. It means someone has to
> | know to load Seaside-DevelopmentFlow (the naming is also an issue)
> | instead of Seaside-Development.
> |
> | <shrug>
> |
> | I don't feel strongly either way - if there's a good use case that
> | requires separating them, I guess that's ok. Anyone else have an
> | opinion?
> |
> | Julian
> |
> | On Thu, Nov 19, 2009 at 5:25 PM, Dale Henrichs
> | <dale.henrichs at gemstone.com> wrote:
> | > Actually only WAWalkbackErrorHandler is in Seaside-Development the
> | others are related to the configuration browser.
> | >
> | > It appears that the 4 classes are the only dependencies upon flow
> | (I've analyzed and run through the unit and functional tests on both
> | GemStone and Pharo ... okay not all of the functional tests, but they
> | are known to be flow free:)...
> | >
> | > It should be straightforward to split them out. So the $64 question
> | is do you guys want them split out?
> | >
> | > I will very likely be making my own split for GemStone, because I
> | want folks to be able to use Seaside 3.0 on top of GemStone 2.3 and
> | the way that flow has been isolated means that a lot of meaningful
> | work can be done without requiring partial continuations...
> | >
> | > Dale
> | > ----- "Dale Henrichs" <dale.henrichs at gemstone.com> wrote:
> | >
> | > | In a GemStone image where I loaded Seaside-Development (modulo
> | the
> | > | Seaside-Flow dependency), the following components/plugins send
> | #call:
> | > | and require Flow:
> | > |
> | > | WAWalkbackErrorHandler
> | > | WAAddDispatcherPlugin
> | > | WAConfigurationBrowser
> | > | WACopyDispatcherPlugin
> | > |
> | > | Note that WAConfigurationBrowser is in Seaside-Tools-Web.
> | Presumably
> | > | the rest of Seaside-Development does not need Flow.
> | > |
> | > | I haven't teased out what else would need to be moved if the
> | above
> | > | tools were packaged together.
> | > |
> | > | I will perform the same experiment in a Pharo-based Seaside 3.0
> | image,
> | > | to see how much of Seaside-Pharo-Developmetn depends upon flow
> | ...
> | > |
> | > | Dale
> | > |
> | > | ----- "Dale Henrichs" <dale.henrichs at gemstone.com> wrote:
> | > |
> | > | | It turns out that Seaside-Development supplies
> | > | WAPrettyPrintedDocument
> | > | | which is used to display the html source for the page...Flow is
> | not
> | > | | needed at all ...
> | > | |
> | > | | Offhand, I don't know which parts of Seaside-Development are
> | truly
> | > | | dependent upon Flow, but I assume that more than
> | > | | WAPrettyPrintedDocument could be split out into a flow-free
> | > | | development package...
> | > | |
> | > | | I will spend some more time digging into this to see if I can
> | find
> | > | a
> | > | | clean split ...
> | > | |
> | > | | Dale
> | > | |
> | > | | ----- "Julian Fitzell" <jfitzell at gmail.com> wrote:
> | > | |
> | > | | | On Sun, Nov 15, 2009 at 2:50 PM, Dale Henrichs
> | > | | | <dale.henrichs at gemstone.com> wrote:
> | > | | | >
> | > | | | > ----- "Julian Fitzell" <jfitzell at gmail.com> wrote:
> | > | | | >
> | > | | | > | On Sun, Nov 15, 2009 at 2:30 PM, Randal L. Schwartz
> | > | | | > | <merlyn at stonehenge.com> wrote:
> | > | | | > | >>>>>> "Dale" == Dale Henrichs
> | <dale.henrichs at gemstone.com>
> | > | | | writes:
> | > | | | > | >
> | > | | | > | > Dale> I would think that if JQuery itself doesn't
> | depend
> | > | upon
> | > | | | Flow,
> | > | | | > | then the
> | > | | | > | > Dale> tests or at least a subset should be independent
> | of
> | > | | Flow
> | > | | | as
> | > | | | > | well.
> | > | | | > | >
> | > | | | > | > I could disagree.  A testing environment might require
> | test
> | > | | | > | harnesses
> | > | | | > | > that are not required for deployment.
> | > | | | > | >
> | > | | | > | > For example, does a running system require SUnit?  No.
> |  You
> | > | | need
> | > | | | it
> | > | | | > | only when
> | > | | | > | > you are trying to test something.
> | > | | | > | >
> | > | | | > | > Similarly, tests for jquery could require Flow, where
> | the
> | > | | | package
> | > | | | > | itself
> | > | | | > | > for deployment does not.
> | > | | | > |
> | > | | | > | Yes, for example, all of our Functional Tests require the
> | > | | | -Component
> | > | | | > | package, even if what they're testing might otherwise
> | not.
> | > | That
> | > | | | said,
> | > | | | > | if we can have all or most of the JQuery functional tests
> | > | | working
> | > | | | > | without Flow (we did the same to the Functional tests by
> | > | using
> | > | | | > | #show:onAnswer: instead of #call:) that would definitely
> | be A
> | > | | | Good
> | > | | | > | Thing.
> | > | | | >
> | > | | | > Is being "A Good Thing" the same as, go ahead and tackle it
> | > | | before
> | > | | | beta?:)
> | > | | | >
> | > | | | > I can take a look tomorrow and see if the majority of the
> | tests
> | > | | fall
> | > | | | into that category...
> | > | | |
> | > | | | If it's relatively easy, sure. :)
> | > | | |
> | > | | | Julian
> | > | | _______________________________________________
> | > | | seaside-dev mailing list
> | > | | seaside-dev at lists.squeakfoundation.org
> | > | | http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
> | >
>