More or fewer abstractions?

[Howard Lewis Ship <hl...@gmail.com>]

On Thu, Oct 25, 2012 at 4:39 AM, Denis Stepanov
<de...@gmail.com> wrote:
> I'm looking into current changes and I have few suggestions.
>
> Some time ago I have rewritten the javascript part of Tapestry using CoffeScript and pure jQuery, I would like to use it in the future with minimal changes, to do so there should be an abstract layer between core components and client logic.
>
> Right now ProgressiveDisplay has this code:
>
> jsSupport.require("core/zone").invoke("deferredZoneUpdate").with(clientId, link.toURI());
>
> it is very implementation specific, I would suggest to create a service similiar to the ClientBehaviorSupport. ProgressiveDisplay will call addProgressiveDisplay(Element element, String clientId, Link link) first parameter should be always element to allow additional configuration. Client side service implementaton could be easily replaced or extended.

See notes before; the last thing I want to do is add yet more layers
of abstraction!  ClientBehaviorSupport was a mistake from the start.

If you don't want something that works like ProgressiveDisplay, write
your own.  What's nice now is just how minimal it is; there's almost
nothing left!

>
> Also Zone component:
>
>
>      Element e = writer.element(elementName,
>                 "id", clientId,
>                 "data-container-type", "zone");
>
>         if (insideForm)
>         {
>             JSONObject parameters = new JSONObject(RequestConstants.FORM_CLIENTID_PARAMETER, formSupport.getClientId(),
>                     RequestConstants.FORM_COMPONENTID_PARAMETER, formSupport.getFormComponentId());
>
>             e.attribute("data-zone-parameters",
>                     parameters.toString(compactJSON));
>         }
>
> should be:
>
>   Element e = writer.element(elementName, "id", clientId);
>
>   clientSupport.addZone(e);
>
>   if (insideForm) {
>         clientSupport.addZoneInsideFormParameters(e, formSupport.getClientId(), formSupport.getFormComponentId());
>   }

Actually, your clientSupport object should be able to determine if
there is a FormSupport environmental, and add the necessary data-
attributes.

>

If you check what I've written, I've been trying to avoid these extra
abstraction layers!  What I'd rather do is better document what the
various AMD modules do in terms of document event handlers, and what
special data- attributes are used.  So if you want a Zone without the
Zone component, it's just a matter of knowing to add
data-container-type="zone", and the "core/zone" module.

> Without the abstraction layer I'll need to fork Tapestry and refactor core components, I like how you can override almost everythink using the IOC but when it is inside component there is nothing you can do.

But if the component is simple enough, you can create a custom one
that does exactly what you want. I think people too often twist
themselves, and their code, into knots trying to customize an existing
component rather than write a few lines of code to create a new one.

>
> If you ask, why did I choose to rewrite javascript logic, it is because I think tapestry should not build own javascript framework/library with all that wrappers and helpers, I can only understand using requireJS to load javascript dependencies. Tapestry javascript support should be one small minified file. Why to have all that modules when everyone could just contribute to the main core module? What are advantages of using jsSupport.require("core/zone") instead of jsSupport.require("core")? Why to have modules like "core/spi", "core/console", "core/events"? I would use requireJS to have modules "jQuery", "underscore", "tapestry-core", "tapestry-core-53-compatibility".
>

The small modules are more pleasant to develop, and easier to debug.
By the time we ship, we'll have a strategy to aggregate (and minimize)
some or all of the modules into a stack.  In addition, small modules
make monkey patching (by contributing ShimModules to the ModuleManager
service) easier.  Don't like how core/alerts works?  Create a
substitute implementation and contribute it.

The module approach is also useful for the way we're tackling some
localization issues, as certain modules are locale-specific (and even
dynamically generated).

> My philosophy is to have simple javascript using pure jQuery without wrappers around ajax, console etc. and using events as the interface between different parts.

That becomes a key question: we would not need the core/spi layer if
we just said "Tapestry uses jQuery, live with it". As I've said in the
past, that is not the best solution for everyone, but I'm willing to
entertain more discussion on this. It would certainly be easier to
eliminate core/spi.

>
> Denis
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>



-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

Re: More or fewer abstractions?

[Denis Stepanov <de...@gmail.com>]

> See notes before; the last thing I want to do is add yet more layers
> of abstraction!  ClientBehaviorSupport was a mistake from the start.
> 
> If you don't want something that works like ProgressiveDisplay, write
> your own.  What's nice now is just how minimal it is; there's almost
> nothing left!

> But if the component is simple enough, you can create a custom one
> that does exactly what you want. I think people too often twist
> themselves, and their code, into knots trying to customize an existing
> component rather than write a few lines of code to create a new one.


I can't just go and replace all components in the project when upgrading to the newest version, there are like hundreds of Zone or EventLink components in our project. I'm doing exactly what you are suggesting, I'm adding data attributes to the existing components, like instead of t:zone I will use data-zone in the new code, but in my mind the best solution would be to replace the code inside the EventLink. 

I'm just trying to come up with the solution to keep things working. 

> That becomes a key question: we would not need the core/spi layer if
> we just said "Tapestry uses jQuery, live with it". As I've said in the
> past, that is not the best solution for everyone, but I'm willing to
> entertain more discussion on this. It would certainly be easier to
> eliminate core/spi.

I don't have a solution here, it is why I decided to rewrite whole Tapestry javascript to pure jQuery. I know it wouldn't be fair to just replace everything and switch to another framework.

In your point of view you see an abstraction on the client side, let's have some base code and share it between prototype and query specific modules, but in my case I want an abstraction at the components layers, so I can just replace whole client implementation. I'm not exactly trying to add more abstraction from my point of view.

Denis



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org