crazy thought

> playing with minimal loads of Seaside3.0 (i.e., no browser loaded and
> sometimes no applications registered) I had a crazy thought that when you
> get the '/seaside not found' that the list of actual application urls are
> listed ... telling you what urls you can use ...
>
> It's crazy but without the application browser, it's a little bit of work to
> figure out what you can load ... especially useful for me would be the
> 'there are no applications registered' variant:)
>
> Dale
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>

> It's been my intention for a while to make Dispatcher know how to
> render a listing of its handlers so we didn't need the Browse
> application. This would need to allow enabling/disabling and probably
> configuration like the WAFileLibrary listing so it can do text/html
> variants. I can't remember if I opened an issue for that, but of
> course I haven't got around to implementing it. It would also handle
> its own (optional?) redirection from "foo" to "foo/" and of course
> enabling listing would be mutually exclusive with having a default
> handler specified.
>
> Mind you, I was only thinking of that for when you hit the Dispatcher
> directly, not for when you request an entry that doesn't exist. I
> guess I can imagine the 404 contents including a listing of available
> sub-handlers... again I guess that would need to be configurable on
> and off. Is that getting too complex?
>
> Julian
>
> On Tue, Jul 13, 2010 at 6:53 PM, Dale Henrichs <[hidden email]> wrote:
>> playing with minimal loads of Seaside3.0 (i.e., no browser loaded and
>> sometimes no applications registered) I had a crazy thought that when you
>> get the '/seaside not found' that the list of actual application urls are
>> listed ... telling you what urls you can use ...
>>
>> It's crazy but without the application browser, it's a little bit of work to
>> figure out what you can load ... especially useful for me would be the
>> 'there are no applications registered' variant:)
>>
>> Dale
>> _______________________________________________
>> seaside-dev mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

> It does seem to be getting too complex ... without the browser, it isn't
> easy to figure out what url to hit ... I loaded the Seaside-Examples on top
> of the Base (no Browser) and didn't know what apps were available until I
> inspected 'WADispatcher default' and even then I had a false start or two
> ...
>
> Perhaps it could be as simple as the default 404 message lists the available
> apps and their urls. the 404 message is something that folks would want to
> customize before they went into production anyway, so it would be unlikely
> to overlooked on your way to production (useful to find out if you
> accidentally had applications hanging around you'd be inclined to notice
> that too.
>
> Dale
>
>
> Julian Fitzell wrote:
>>
>> It's been my intention for a while to make Dispatcher know how to
>> render a listing of its handlers so we didn't need the Browse
>> application. This would need to allow enabling/disabling and probably
>> configuration like the WAFileLibrary listing so it can do text/html
>> variants. I can't remember if I opened an issue for that, but of
>> course I haven't got around to implementing it. It would also handle
>> its own (optional?) redirection from "foo" to "foo/" and of course
>> enabling listing would be mutually exclusive with having a default
>> handler specified.
>>
>> Mind you, I was only thinking of that for when you hit the Dispatcher
>> directly, not for when you request an entry that doesn't exist. I
>> guess I can imagine the 404 contents including a listing of available
>> sub-handlers... again I guess that would need to be configurable on
>> and off. Is that getting too complex?
>>
>> Julian
>>
>> On Tue, Jul 13, 2010 at 6:53 PM, Dale Henrichs <[hidden email]>
>> wrote:
>>>
>>> playing with minimal loads of Seaside3.0 (i.e., no browser loaded and
>>> sometimes no applications registered) I had a crazy thought that when you
>>> get the '/seaside not found' that the list of actual application urls are
>>> listed ... telling you what urls you can use ...
>>>
>>> It's crazy but without the application browser, it's a little bit of work
>>> to
>>> figure out what you can load ... especially useful for me would be the
>>> 'there are no applications registered' variant:)
>>>
>>> Dale
>>> _______________________________________________
>>> seaside-dev mailing list
>>> [hidden email]
>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>
>> _______________________________________________
>> seaside-dev mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>

> Julian Fitzell wrote:
>>
>> I dunno... I'm reluctant to expose that information by default just to
>> allow for a case of someone who (a) has a minimal install and (b)
>> doesn't know what is in it.
>
> That's one of the reasons that I figured it was a crazy thought.
>
> On the other hand, there's an awful lot of code that gets loaded and it is
> asking a fair amount for folks to know everything that gets loaded
> especially when things are still in flux.
>
> I ran into the issue and assumed that I might be pretty close to the first
> person to run into that problem and assumed that I won't be the last...

> On Wed, Jul 14, 2010 at 12:25 AM, Dale Henrichs <[hidden email]> wrote:
>> Julian Fitzell wrote:
>>> I dunno... I'm reluctant to expose that information by default just to
>>> allow for a case of someone who (a) has a minimal install and (b)
>>> doesn't know what is in it.
>> That's one of the reasons that I figured it was a crazy thought.
>>
>> On the other hand, there's an awful lot of code that gets loaded and it is
>> asking a fair amount for folks to know everything that gets loaded
>> especially when things are still in flux.
>>
>> I ran into the issue and assumed that I might be pretty close to the first
>> person to run into that problem and assumed that I won't be the last...
>
> Well, I do think Dispatchers should list their contents by default
> when no child is specified in the URL and no default has been
> provided. This guarantees you would see something when you go to / at
> least. It's only the 404 that I'm not so sure about.
>
>>> The OB tools provide a way to browse the handlers as do the web tools.
>>> Maybe we just need a slightly better API on WAAdmin to expose that
>>> information. I think it's reasonable to expect you to have *some* set
>>> of tools installed if you want a convenient way to work with the
>>> install.
>> OB tools for production would fill the bill ... and they could be added to
>> the Base group (and even opened by default) ...
>
> I think we load Tools in base so I don't have a problem with including
> OB-Tools in theory (on platforms that have OB obviously), but I'm not
> sure about pulling in OB if the image doesn't already have it?

> 2010/7/13 Julian Fitzell <[hidden email]>:
>> It's been my intention for a while to make Dispatcher know how to
>> render a listing of its handlers so we didn't need the Browse
>> application. This would need to allow enabling/disabling and probably
>> configuration like the WAFileLibrary listing so it can do text/html
>> variants. I can't remember if I opened an issue for that, but of
>> course I haven't got around to implementing it. It would also handle
>> its own (optional?) redirection from "foo" to "foo/" and of course
>> enabling listing would be mutually exclusive with having a default
>> handler specified.
>
> The Dispatcher is in -Core so it can't use Canvas to render HTML.
>
> Cheers
> Philippe
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>