[Cuis-dev] success with WebClient package

Mark Volkmann r.mark.volkmann at gmail.com
Mon Jun 17 14:42:30 PDT 2024


Thanks so much for taking a look at this! See my replies inline below.

On Mon, Jun 17, 2024 at 4:28 PM Andres Valloud via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> Why don't all branches of GET return nil?
>

I'm handling two cases for GET requests ... JSON and HTML. The handleDog
method doesn't need to return anything. It just needs to cause an HTTP
response to be sent. The methods getDogsAsJson and getDogsAsHtml do that.
The only reason I have "^nil" in several places in this method is to return
early from handleDog and not evaluate the rest of the code.

So given all that, is there a better way I could write this?

Do you need to return nil, or is just returning self enough?  How about
> returning e.g. ^self getDogsAsJson: aRequest?  That reduces lines of
> code quite a bit.
>

Perhaps if I do what you suggest, the return value will just be ignored ...
which is what I would want to happen. I was thinking if I returned a value
other than nil, readers of the code would think the return value had some
meaning or was useful. But in this case that would not be true.


> How many methods are there?


There are only four. The only one I'm not supporting here that is sometimes
used is PATCH, so a maximum of five.


> If there are many more than 4, a dictionary
> might be in order.  Or another take:
>
>         handleDog: aRequest
>
>                 aRequest doDogCrudWith: self
>
> and let the request ask the questions about method, header etc to self,
> rather than the questions being asked to aRequest here.  Push the
> responsibility closer to the actual objects involved.
>

aRequest is a WebRequest object from a class defined by the WebClient
package, so it's not my code. I know I could still add methods to it even
though it's not my code, but I thought perhaps it would be frowned upon to
add app specific methods to a library class.


> On 6/17/24 2:20 PM, Mark Volkmann via Cuis-dev wrote:
> > I finally have a set of HTTP CRUD operations working using the WebClient
> > package!
> > The following is a method that handles requests for all URLs with the
> > path "/dog".
> > Regardless of the HTTP method, all requests pass through this.
> > This code works perfectly, but I'm questioning whether it is idiomatic
> > Smalltalk code.
> > What would you do differently in this code?
> >
> > handleDog: aRequest
> >      "handle an HTTP request based on its method"
> > | id parts |
> >
> > aRequest method = 'GET' ifTrue: [
> > | accept |
> >
> > accept := aRequest headerAt: 'Accept'.
> > (accept includesSubString: 'application/json') ifTrue: [
> > self getDogsAsJson: aRequest.
> > ^nil
> > ].
> >
> > (acceptincludesSubString: 'text/html') ifTrue: [
> > self getDogsAsHtml: aRequest.
> > ^nil
> > ]
> > ].
> >
> > aRequest method = 'POST' ifTrue: [
> > self createDog: aRequest.
> > ^nil
> > ].
> >
> > "Get the path parameter value."
> > "TODO: Is this really the best way to do it?"
> > parts := aRequest url prefixAndSuffix: $/.
> > id := parts last asNumber.
> >
> > aRequest method = 'DELETE' ifTrue: [
> > self deleteDog: aRequest id: id.
> > ^nil
> > ].
> >
> > aRequest method = 'PUT' ifTrue: [
> > self updateDog: aRequest id: id.
> > ^nil
> > ]


-- 
R. Mark Volkmann
Object Computing, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20240617/cac8ed86/attachment-0001.htm>


More information about the Cuis-dev mailing list