This views:
PluggableSelectionWebView / PluggableQuestionWebView / PluggableMultipleSelectionWebView / PluggableMessageWebView can be removed if the JQuery UI Dialog is refactored a little.

Some affordances automatically serializes the component content when applied to it's trigger. This is not explained in the documentation and can be confusing for newcomers. A serialization chapter is needed in the docs to better explain it.

Can be a good time to also explain which affordances are pure client code, and which will perform a server call.

Some behavior implemented in this command is probably better suited for DelayedCommand.

It should be easy to implement looking at the implementation of: WebInteractionInterpreter>>enable: (and not forgetting to implement it on the other class in the hierarchy)

As reported by @seandenigris in #127 this fields are missing some behavior.

Create an example Seaside app showing the library use.

See https://www.w3.org/TR/html401/interact/forms.html#edef-LABEL

Render a label as a wrapper cannot be used when a table is being used for layout. Also you lose some style control.

Currently sending onTrigger to a component / web view will return a configurable interaction interpreter, related to the most common interaction for it. This is onClick for buttons, onChange for text fields, etc.
The proposed improvement is to allow any component to be configured for any event available.

https://blog.jquery.com/2020/04/10/jquery-3-5-0-released/

Move commands and specific classes to JQuery UI Packages.

Use case:

aText := self componentSupplier singleLineTextFieldApplying: [ :theField | ].
aButton onTrigger setValueTo: 'Some other text' thenTriggerChangeOf: aText.

leads to 500 (Internal server error) with 'The identifier was never assigned'.

Is it possible that components self-identify if needed, instead of doing

aText identifyIn: html.

"by hand"?

The Dialog handling logic is working just for jQuery UI as the frontend, something needs to be abstracted to allow the use on different frontends.

As discussed in #114 we need to simplify TableWebView instance creation and review the API of TableWebViewBuilder to easily combine the footer, heading, and column definitions without a method explosion.

Since 3.5.0 has some breaking changes as noticed in jquery/jquery#4665

Is it a good idea to provide a instance creation message without the last parameter. It would be #displaying:boundTo:

I have a couple of examples where I'm always passing [ :label | ] as an argument.

AsynchronicAnchorWebView declares the attribute role="button". A recommendation of bootstrap for anchors styled as buttons.

We already discussed this and distilled these tasks:

• Move out AsynchronicAnchorWebView from AsynchronicButtonBehavior hierarchy.
• Remove role="button" from AsynchronicAnchorWebView.
• Add preventDefault to AsynchronicAnchorWebView. It's asynchronous but if you add the href attribute to it, it will still go to the referenced URL.
• Rename references to asynchronic anchor for asynchronic link
• Add to bootstrap component supplier as non-portable #asynchronicLinkActingAsButton with role="button" and class="btn".
• Remember to do this refactoring with rewrite rules based deprecations

Almost all apps end up adding some additional libraries and now you have to reimplement updateRoot: and send it to each one.

Maybe we can provide something like WillowApplication>>#requiredLibraries , so the user can provide a list of required libraries and during WillowApplication updateRoot: processing take that into account and send updateRoot: to each one.

Thanks @macta for the idea.

Support for bootstrap 4? What would it take?

The current protocol lacks a command to do a Javascript evaluation to decide whether to call the server.
Ideally it would be a mix of
evaluate:with:
confirmAsking:
executeOnClient:

Some components already include a serialization command upon creation, so sending to its interpreter a serializeIt action ends up in a duplicated field sent in the AJAX Post. This is problematic to some web servers.

If we can detect this duplication we can warn the user about it before running into the problem.

ComponentValueSettingCommand currently has a confusing number of instance creation methods, not all are accessible from the component supplier, and the protocol should be simpler considering the changes in v14.

Rename the base package from Willow to Willow-Core. This is to ease importing into VA Smalltalk, where the name of a package is used to create a class, and classes can't have the same name as pool dictionaries. We already have a pool dictionary named Willow.
Also, update the dependency to Boardwalk to use release 5.0.0.

A lot of components already have the self-identification protocol in place, but cannot be used in several commands because the commands will send to them view. If we used instead of view some message that can be implemented in other component returning self, we can avoid many uses of IdentifiedWebView

evaluate: --> serverDo:
evaluate:with: --> serverDo:with:
executeOnClient: --> userAgentDo:
determineBehaviorByEvaluating: --> serverDo:
determineBehaviorByEvaluating:with: --> serverDo:with:
onlyWhen:determineBehaviorByEvaluating: --> onlyWhen:serverDo:with:

Now that Pharo 7 supports Tonel, the builds are failing due to:

Project: Seaside3 baselineMetacelloNameNotDefinedError: project group, or package 
named: 'Seaside-Pharo-Development' not found when used in requires: or includes: field 
of package: 'Seaside-Tests-Pharo-Development' for version: baseline of BaselineOfSeaside3.

Sometimes you want to change a component value without triggering the change event, so make it configurable.

Adapt WebInteraction senders to be:

setValueTo:thenTriggerChangeOf:
setValueTo:withoutTriggeringChangeOComponentWithId:

The individual Playground examples are really nice and easy to adapt, but I'm unclear on the overall design. For instance, the examples seem to override the session and application context. How would I know if this is necessary or appropriate for my app? Another example, WPLiveDocumentation overrides #initialRequest:. The method comment in WAPresenter>>#initialRequest: says "When a new session is started, all visible presenters (components or tasks) receive this message with the request as argument. A common usage for this is to initialize their state depending on the URL of the request." However, WPLiveDocumentation throws away the argument. It's unclear what the pattern is here…

Currently, when starting an app either in deployed o in development mode, the error handler configured is the AjaxAwareErrorHandlerFactory. Although is useful that each subclass has the posibility to implement the specific handling overiding errorHandlerFactory, would be useful that when using the development mode that the error handler configured by default is the debugger, because most probably is because we're coding and the exceptions that arise we would want to fix it in the moment, and the ajax handler just makes it all very unconfortable.
Maybe WillowApplication can colaborate with the WADeploymentMode with a double dispatch pattern and end up configuring the proper handler, keeping the posibility that each application subclass overides the deployed or the development handler.

Right now we have a lot of methods with several tiny variations involving what to do with the class and how to match the component. Look for implementors of:

• addCssClass:*
• changeCssClass:to:*
• removeCssClass:*
• toggleCssClass:*

I think we can have only two methods in the interpreter:

• updateClassList:
• updateClassList:onElementsMatching:

The first one will apply the changes on the DOM element starting the interaction, the second one allows to use some logic to match the element.

So we can have something like:

[:classList | classList addClass bootstrap button ]
[:classList | classList addClass: 'xxx']
[:classList | classList removeClass bootstrap button]
[:classList | classList removeClass: 'xxx']
[:classList | classList toggle bootstrap button]
[:classList | classList toggle: 'xxx']
[:classList | classList replace: 'xxx' with: 'zzz']

for the first argument and

[:document | document getElementsByClassName bootstrap button ]
[:document | document getElementsByClassName: 'pepe' ]
[:document | document getElementsBySelector: [:selector | selector form class: #bootstrap ]]
[:document | document getElementById: #aaa ]
[:document | document jQuery blaballa ]

for the querying capabilities

Add footer support (optionally) to the table and table builder. Useful for simple cases. The actual rendering must be delegated to the column renderer.

The already provided commands must ensure using #identifyIn: that the component has assigned an id.

Provide a FAQ also for the cases when the user are doing it for example using executeOnClient: explaining how to get rid of the problem.

Currently AJAX calls are always made as POST requests. A better default is to not configure it as POST, and make this configuration in the necessary commands.

See https://www.w3.org/TR/2012/WD-html-markup-20120320/input.email.html

This is required to improve alternative uses of the command.

http://blog.jquery.com/2019/04/10/jquery-3-4-0-released/

By default the WADebugErrorHandler is not loaded,
so explain how to load it and how to configure the application to use it.

HTMLAsserter can't be used with an empty string.

clientIndependentActions are almost never used in the Willow commands, and they could be merged when needed with modelLoadingActions.
Also block parameters should be made optional.

Now that #134 is done, we should think about adding better support in the block argument to easily reference known classes, as was originally proposed in that issue.
This should be done in a similar way (and reusing protocol) as can be done when configuring a command via something like [:view | view addClass bootstrap button]

Hi Gabriel.

I have everything loaded into Pharo 8. Thanks.

I'm working through the tutorial now.

Will the latest version of Seaside and Willow be available soon for VW?

How can I communicate with you via e-mail? The response you sent me was from a no-reply address. Should I post to pharo-dev or pharo-users instead?

Shaping

README refers to "#willow channel at ba-st.slack.com" but I couldn't see it:

@mtabacman what's your opinion on combining

• determineBehaviorByEvaluating: with evaluate:
• determineBehaviorByEvaluating:with: with evaluate:with:

So if you provide a parameter in the block for evaluate we inject the response and behave like determineBehaviorByEvaluating is doing now.

So you can do:

evaluate: [ ... ]
evaluate: [:response | ... ]
evaluate: [:parameter | ... ] with: xxx
evaluate: [:parameter :response | ... ] with: xxx

The docs need to be updated to explain about:

• WillowApplication
• Deployment Modes
• Error Handling (Sever and Client side)
• Libraries provided by the component supplier
• Additional libraries
• Sessions and Contexts

Currently the condition supplied has to be a String because the code creates a JSStream over that. It could be better if we can also pass a JSObject that eventually will evaluate to a boolean.

This shouldn't be difficult to do.
We need to change DelayedCommand>>considerAddingConditionTo: anAsynchronousCall and provide some backward compatibility (or at least migration support)

Hi Gabriel.

I'm not sure my direct e-mails, sent in response to your first reply, are being received.

I've been trying to port from VW to Pharo for almost 14 years. Pharo still has serious basic GUI problems, like not being able to accommodate a small change in font size without truncating labels in, for example, Setting and the Iceberg client. I recently posted an example of this, with a screenshot, to pharo-users and pharo-dev. Users and devs seem not to be able to see that correct framing of text renderings is broken in Pharo, in spite of all the slick GUI improvements, like GT. Or, they just don't want to bother with the fix until Spec2 is ready. This basic flaw and the general slowness of the GUI have kept me away. Spec2/GTK3 is here, I think--and that will provide the needed snap in the GUI--but the key issue is whether anyone is actually now using Spec2 to retool, say, the System Browser. I don't know. Do you?

As I read through the Willow materials, I'm increasingly impressed with the grace and utility of this framework. Thank you for your work and good use of common sense.

I have a time-series (candlestick chart) app I'm implementing from scratch in VW using, not Wrapper (a big pain), but the Panel hierarchy (prototypical, never officially released by Cincom). I'm also trying to revive Cincom's Widgetry (better than Wrapper, but still another failed incomplete, buggy framework). All of this work seems like a waste of energy when I see how beautiful web GUIs are in the jQuery UI.

The latest Cincom Seaside is from 2017-06; the latest Willow is from 2003-03. The Willow version is clearly old. I'm not sure about Seaside. I think it has been updated since then, but I don't know why it would not be also in the Cincom repo. Do know when these will updated in the Cincom repo?. I would like convert my local-client app to a web app, and build it with Seaside and Willow.

To use Pharo, I would need to prot, and I have little time and a lot of code. Pharo's Git interface still concerns me. I've never been able to make it work reliably in Pharo, even when I can read the text labels.

I would like to practice with Willow anyway. Can you tell me how to proceed with Willow in Pharo 8 64-bit (stable)? The prebuilt Willow playground image appearing in Pharo Launcher 2.0 is broken. I get walkbacks just selecting items in the tree after launching the demo.

Thanks.

Shaping

The new checkbox view does render the checkbox correctly after using the model setting messages.