Johann Werner: I will talk about dynamic elements, keeping the talk quite on demos, to show you how to create such components. My name is Johann Werner, and I'm working at a Germany based company called [indecipherable 0:00:23] .

The talk will be about components on the [indecipherable 0:00:34] , so we will first have a look at, what is a component? Then, take a look at what types of components we can create to come to the dynamic components where we will have a closer look at.

Components, the definition is, it's a reusable piece, we use on a multitude of pages and other components. It consists of our representation part, which is our template, and functionality, which is represented by our Java codes.

As you hopefully all know, WebObjects has a big number of components which it can use within your own templates, like word repetition and others, and wonder which comes with even greater number. Probably, all will have your own frameworks with different types of components for your needs.

The structure of such a component is divided into several files, so, starting from top to bottom, we have an API file where we define several bindings which are used to transfer information from parent to children components. It's mainly used for Eclipse to make our auto-completion work. It's optional that you should use such files.

Then, we have our Java file, which defines our functionality, where you put your logic that is custom for your own component. Then we have the template related files, first the template, where we use any, most of the time other components or hard coded strings or HTML structures. Then, we have the definition files, where we list all bindings we are using in our template, so WebObjects knows where to pull data from.

The last one is the root file, you probably won't ever handle this file, and it's, normally, you don't have any usable information within. It's kind of legacy file. As in former times, we had different types of encoding. So within that file, it's defined in which encoding our template is written in. But nowadays, you probably will have everything in UTF-8.

What types of components do we really have? Let's start with, I call it, standard component. Standard components is defined by being a sub-class of WOComponent.

That WOComponent class gives us automatic binding synchronization. So everything we're connecting via bindings are automatically pulled into our components. If we change those values, it's pushed back to the parent class. Of course, only if it's possible. So if you have a hard coded string in the binding, of course, it won't update it.

The big feature of WOComponent is preserved state. So when the [indecipherable 0:04:52] response loops terminate, you won't lose any information. The next time the user comes back and reuses exactly that component on your page, everything will be in place, like you left it.

So how does it look like? We have any parent component, where we insert my string opponent here, with the value binding.

Looking at the component itself, we have a template which was really easy in this example. We just print out a string. Within our component, we extend WOComponent, have an instant variable with the same name as our binding. The rest is automatically done by WebObjects.

So, that's the automatic synchronization. That's quite comfortable.

Now, what if we don't need automatic synchronization. Then there is the next type of component, the not synchronizing one. So as the name implies, we have a manual binding synchronization.

Often, you as a programmer, exactly know when you're needing a value. Or if you're changing a value and you need to send it back into your parent component. WebObjects has to guess it could be permanently changing so it will often push the value back and forth, even if it's not needed. Going to manual synchronization means you have less overhead so your component will be a little bit faster. As the normal component, it will preserve state so a little bit of optimizing your components.

If we look at the component, itself we see the code changes a little bit. The template keeps the same but now our instance variable is gone and to indicate to WebObjects that we want to manually synchronize our bindings we override the method synchronize variables with bindings and return false. That's it.

Now, we're forced to fetch ourself the bindings. That's why we have a method called value and that will fetch the value from the parent.

For our non-synchronizing component, we have a certain notation where we can even make this code easier and that's the caret notation. What does it do? We change our template, insert a caret where we want to indicate WebObjects. Don't look for that value in our component, look at the parent one. We can remove our value method.

Then, going a step further, we have stateless components. As a non-synchronizing component we have to manually push and pull our values, meaning we have less overhead, but then we have no state. This means if we are ending our request-response loop we have to be aware that we can't rely on any instance variable value. The advantage is that WebObjects will try to use a single shared instance for generating output.

There's the little asterisks. We will see in a minute why it's not exactly a single shared instance. The consequence is, of course, we use way less memory because we have only one instance, one Java object. As we have only one Java object, we don't create a lot of objects. As you know, creating an object in Java can be costly, depending on the object itself, of course.

Back to our code, we see barely something has changed. Instead of synchronize variables with bindings, we have overwritten the method as stateless and returned true. Again, that's all.

The stateless component has no state between two request-response loops, so what should we do if we are forced to use an instance variable? That's easy.

Let's say we have an object variable myVar. In that case, we have to override our reset method and set all those variables we are using to null. The component, after being used, is really in the same state as we picked it up. The mistake that is often made is to forget to call super. First thing you do if you are overriding the reset method, call super.

Then we have dynamic components. Of course, all these three types of components we saw so far are, of course, also dynamic because the output generated can change over time depending on the binding values you are pushing into it. I call it dynamic component as often in the Apple documentation dynamic component, the name, is referred to subclasses of WODynamicElement. It's not a really good name, but I think we should stick to it.

The big difference to the normal components is we have no template. That component is completely done in code and that means we have no need for parse and no substitution of values within a template. That means, again, we need less memory and we can generate all our output faster.

Then a dynamic component brings in some features we don't have in other types of components, and that is we have direct access to those objects representing our bindings, the WOAssociation objects, and we can access our children. Everything that's wrapped by our component is accessible. That you cannot do in normal components. Of course, there are many occasions where you really need to access children, but when you do you have to use a dynamic component.

The big downside is that this class has to be threat safe and that's often a problem because concurrency is sometimes difficult. Going back to our code, we see our template is gone. In that case, we see in the constructor we're getting our association for the value binding and the main method we have in a dynamic element is a pent response where we generate our content that is put into the response and sent back to the client.

We are using that binding association to get the value from the binding. If you're thinking of stateless component and the example we had myVar instance variable and we had to clear it at the end of the request response loop. Here we have an iVar, too, so where's the reset method? The answer is we don't need one here because an association object isn't the real value itself. It's only an object that gets the value from a certain point of the object graph. There is no problem with concurrency here.

We will have a little demo looking at those different types of components, how they are used in a normal application. I prepared a little project where we have four pages, one showing one single type of component. We have my string which is a standard component, we have a my string non-synchronizing, a stateless one, and a dynamic one.

What we will be doing here is using the Apache benchmark tool to hit those pages several times. Here we will make 500 requests and look at how the response times average.

Let's start the project. Here on main page, I maintain a counter. Every time when an object is created, I add one to the counter so we see how many Java objects we are really creating for all those requests.

I wrote a little script that will first hit page one 500 times, page two, page three, page four, pass the output of Apache benchmark, and give us just the result what's the average response time. Of course, don't take the numbers serious. It's only a tendency because you don't know what's happening in the back. Perhaps the GC is jumping in right within our requests changing the number. It gives us a tendency how fast those different components are.

If you are looking here, we see the standard component is the slowest. It's logical because there is much automatism within it which costs time. Then next we have the non-synchronizing component which is a little bit faster because we are removing all these automatic codes. Then the stateless one is even a little bit faster and the dynamic component, as we don't parse any components, is the fastest one here.

If we look at how many objects we currently have in our application we see for all the normal and non-synchronizing component we created 500 objects. That's, of course, adding two to the slower request. In the stateless and dynamic, we only have one instance, though we access that page 500 times. If you're concerned with memory, that's a big plus.

Now, we will change our test a little bit in saying we want to rerun everything but make it two requests concurrently. Before I'm doing this, I will stop and restart the application to reset our counters.

Now we refresh and now we see we have here 501. Don't ask why it's not 500. I don't know. We have 500 objects and the stateless one has two. Why does it happen that we have two?

In that case, we have the stateless component we said has no state and it's reused as a single shared instance, but then during a request-response loop, it has state so you can put values into your variables and be sure that until the generation of the output is done, those variable values are maintained.

Now, we have two concurrent requests both hitting the page at the same time. So WebObjects sees, "Oh, that instance is already used and I cannot use it again because I will delete the content of the variables," so it creates another one.

We are getting as many instances as we need at the same time but only that much. The dynamic component, instead, we are keeping one single instance because we are threat safe so it can access that component at the same time so no problem.

Again, let's change a little bit of our test in that we are doubling our components within our parent template. Running, again, our tests.

Now, for the standard and non-synchronizing component, as we expected, we have two times the number of components to be rendered so we have two times the object count, but then stateless is back to one. That's OK because those two components are following each other, so when we're hitting the second stateless component, the first one has already finished so we can reuse that component.

On the dynamic side, we have two now so what happens there? Why didn't it stay at one instance? Because it's threat safe there shouldn't be a problem. If we're looking at the constructor of a dynamic element, here the my string dynamic class, we see the last argument of that constructor is a template. What's the template?

Here our children elements are within and if you're thinking of a component that can have content, that grabs content, if we have that component in different locations within a page it could differ. Of course, here we don't have any content, so it's the same but WebObjects doesn't know. It could change. For example, you could have a condition and the real content changes so it will have to create for each location on the page a single instance to be sure that the content is separate.

What did we learn from this demo? We have seen the more specialized the class is the faster it gets, even if it's only a small difference between those instances. You have to think of those templates as really simple. If you have lots of complex pages, it can add up. Stateless and dynamic components would create way less Java objects. If memory has to be conserved, you should go for stateless and dynamic elements where you can.

Let's sum up when should I use the different types of components. Beginning with the standard components, those would be used for your pages or if you have big blocks on your pages where you have many elements. It makes sense to keep those as normal WO components because you don't have to mess with all the binding synchronization if you have a big number of those.

Then non-synchronizing components are good if you have many small components and they are used at many places. Another causal would be to use non-synchronizing if the name of your binding differs from the variable where the values are pushed into.

If you have to support legacy binding APIs, you would have to use a manual synchronization, or even if you decide you don't want any instance variable, you would have to go with non-synchronizing, too.

Going next, stateless component, of course. If you don't need any state, taking our example of my screen, I'm just pushing through a value. Why shouldn't I have state? Stateless would be fine. If you want to optimize the memory consumption of your application, that would be a fine choice, too. Then the dynamic components, of course, no state necessary and then it's fine to go dynamic, too.

Sometimes you have to generate output that is really complex where you have many computations where it could become difficult or too complex to construct this by a template, a normal template. Or if you have some components where you need the access to your elements, then you would have no other choice than to use a dynamic one.

If we have a look at the component class tree that we have nowadays, we see there are many classes that can act as base classes. Our three types, standard, non-synchronizing, and stateless. We can find counterparts in Wonder that you can directly use and subclass. Then the talk is about dynamic elements so I want to create a dynamic element. Where should I start off?

We saw it has to be a subclass of WODynamicElement, and that leaves us with that power of the tree.

There are many classes left, so which one should we do? Which one should we use? How would you solve this problem? Of course, you're looking what do the others do? What did they choose? Then you're starting looking at different components and their parent class and then you see there's a problem. Every class is used and I don't have a clue which one is the appropriate one for my case.

For the standard components, we had base classes in Wonder, so why would we add a base class for that one? There will be in the next days a new base class, ERXDynamicElement, that you can choose as a starting point. The current Ajax dynamic element is now a subclass of that one so every functionality that you could use or want to be edit we have now a thing in place where we can edit.

I don't want to go directly into a method list or API listing for those classes you can use. We just will jump into another demo where we will construct the other component. You can directly see how to create one dynamic class. We will use the ERXDynamicElement class, which will be an ERX extension. Let me construct a case, an example, we will implement now.

We will make two components. One component will be a wrap component and the second one will be an item component. Think of something like an unnumbered list and a list element. We'll start with a fresh project.

We will start with a main component where we will just insert our components to create. We have a my string list. This wraps an arbitrary number of my string items.

Now, we will create those two components. As it is a dynamic component, we don't have any component template. We just create the Java classes.

Have a look at those components. Here we are extending ERXDynamicElement. The main work happens within the parent response. We see here we are creating a div class, adding the class attribute, and then we say I'm done for now. Please first enter the response from my children. Then if that's done, we close our tag. Really straightforward.

Looking at our string item, we see it's nearly the same. Here, again, we are creating a div, we're adding a class attribute, and now we're getting, from our binding, the string value, and then we close our tag. That's it.

Here we would already be finished. We'll be using that component in your applications. It would be fine if Eclipse had auto-completion for your bindings so we need to add API files.

Unfortunately, there is no new create an API file. It gets only created with component files. We will just manually hack the file. We're just taking the API file from our main component, which doesn't use it.

As it comes from main, it has included the Java name. Of course, this doesn't match with our class so we'll change it to the correct one. Now we have the API file in our API editor.

As we can see here on main, I want value bindings so I'm just adding it here like any other component. Let's say it's required. That's one.

Looking at our template, we see the output is as expected. If we were looking at the HTML code, we see we have our div with the class list retainer created by my string list and we have our three items with the class list item.

That wasn't really magic. Let's get on and add some features. We have a list of items and we want our container to put in a status line saying we have that many items.

What are we doing now here? We have the same procedure but after the parent-children response, we add another div and we want to print out X items for this list. Here we can access our children directly so we are iterating our children elements looking at oh that's a my string item so I'm increasing my count and then putting it out to the response.

We see it successfully counted three items and added the correct output. Now, we're just getting a little bit more complicated. Let's pretend we're wrapping one of our items with any other component. Here, to keep it easy, we just make condition and we're just saying true. It doesn't matter. Reload the page. We see two items. Why is that? If we're looking at our iteration, we're taking children elements but what does it mean?

Children elements here are the direct children of our element, not the whole element tree. One solution would be to either make a recursive call and going through all that hierarchy checking how many my screen items do we have, but then who knows how complex the hierarchy can be? We don't want to put in there code we don't know or else will take forever. Who knows? So we have to find another solution.

We're going into direction of keeping some sort of state within our component. Then we have to maintain threat safety. What should we do? In ERXDynamicElement, there is a little helper class, context data.

Having a look at our changes, we have here an instance variable with the context data. We see our parameter response has little change in that we are calling a method before processing first and at the end calling after processing.

What does this do? If we are looking here, both methods are declared with an ERXDynamicElement but they are empty. They are only there to be a place where you can overwrite and put your logic into. In here, we are calling on context data begin method where we will stuff a certain value into it. Behind the scenes, that will be put in our current context. After our processing, by calling and, we'll remove that value.

It's only a way to access our value like a global association object. We don't have to think about threat safety because the value isn't stored itself within that variable but in our context.

Now, in our item element, here we can have the very same context data element and that's keeping track of by a key. That key should use the name of your component dot the name of the variable you're tracking so you can directly match where does it come from.

The difference here is we're getting our current value through the variable. I'm seeing I messed up the order of the things I wanted to do. Here, the task was we are having a list of items with a container and now we want to make it configurable. What type of HTML tag are used for items? The easiest way would be to add a binding to our items to make the element name of our item configurable, but then we would have to add each item binding value and that's tedious.

We already have a container. Why can't we add it to our container element? That's happening here. Here again, first, we want to have auto-completion within our Eclipse environment, so we are creating another API file.

Here, again, thinking of changing the Java name. Value doesn't interest us on the list element, but we have the item element name.

We are adding here the item element name and we say OK, we don't want a div we want a span. Now what happens if we are going through? We're jumping here into before processing. We say OK, we want to keep the value for the binding item element name. Then if we're in our item element, we just say give me the value for that variable. Here we are just checking do we have a value? If not, take the default, the div, and construct the very same element.

We see now we have lots of spans so that worked. Now back to our problem with the conditional giving us a wrong item number. The problem is we are going here in the list, checking our direct children elements, but the third one wasn't a direct child anymore so either we have to recursively go through all that stuff or another method would be each item has to say I'm here. That's the way we'll go.

Let's see the changes that have been made. Now instead of one context data element, we have three. The first one, item count, now holds our count of my string item elements. That's clear. Now we have also a container and that container will represent our list items. It makes sense as the item element name and item count are used on the list element to keep that information on that element and don't pull it into the item as we did with item element name before.

To give the item the opportunity to say I need my own list element so that I can ask the item element name from it, we have to put the element itself into such a context data. To make it accessible to others, we have a static method Current Container and that will just fetch the value out of the context.

For the items, we added here an increment item count method as a convenient method that will increment the value and item count by one. Here we see in before processing and after processing, we are just adding those two variables of context data and initializing the first count with zero. In our item, it gets a little bit easier, we don't have any context element, context data, because we said we're keeping that all within the list element.

We only need to call our static method give me my current container. As the context is the same and it's passed around, we are sure we're getting the correct value out of it. Now, we can say give me the item element name from that container and after generating our output, we are just calling increment the item count. I have been rendered into the response so I'm really there.

Restarting our app. We see everything is fine again. There are three items and it prints three items. It seems a lot of work to keep here the count. We're needing three context data objects. By doing that, we can nest those elements so internally we're stuffing those values within the context but we have a stack. By just making the list nested, we have a list and within the list, we add another list. We could add further ones.

We just reload the page and we see it gets inserted in the correct place, it gets the correct number. There is no problem in having to think of I am putting the value here but what if I have nested components? Will they override and everything? We just use context data objects and we are done.

So summing up, the creation process of a dynamic element, we have some simple steps to follow. First we have to choose either ERXDynamicElement or Ajax dynamic element to sub-class. Then the main task is to fill out the content response. There we have several helper methods.

First, the most one used will be append content string. So that will be added to the response object. Then we add a Pentech attribute to response, which will add attributes to our task. There is automatically a check, is the value there or is it not? If it's not, no element will be added. Also, it will handle inserting a space if you're adding a class. So you don't have to bother with it.

Then if we know we have children elements, we just call a parent-children response to generate their content.

Then we have many different flavors of value for binding to get to our values. All those association objects are ultimately tracked. So we don't have to take the correct bindings and keep them around. It's just there. Call string value for binding and you get a string. Call Boolean value for binding and you get a Boolean. Then we have the context data, if you're going to be using more complex constellations of dynamic elements.

So now we have an, of course, constructed example of two elements. But you can add many more, make complex layouts, add checks. For example, a list element could throw an error if you have only two elements, because three, at least are mandatory. Anything you can imagine.

For contacts data, use before processing and after processing, to clean the value afterwards. Of course, it can use any other low dynamic element. But I think it's good to have a common point of extension. So thinking of committing new elements to Wonder, we will have a certain style in every component. If you're looking for arrows and back fixes or want to learn how to make those components, you can have a look at Wonder, and getting a certain style.

That wraps up my talk. I hope you're ready for creating your own dynamic elements and committing them to Wonder. [laughs]

[applause]

Johann: Any questions?

Man 2: I really appreciate your presentation, especially the term dynamic element and thinking of a dynamic component. I learned something today. I always thought of dynamic elements as strictly inputs. Like in input on a form, something that did not have children. I always thought about, with the role associations, that you add an extra binding like on-click, it will just show up as on-click inside the HTML element. I always thought of it as an HTML element and a dynamic element.

I always thought that was the way it goes. But today I learned that you can actually children inside of a dynamic element. And you can reach out and touch them. It's a subtle thing, but very profound. Because normally, with WOComponents, we can find the parent. We cannot find the children.

Johann: Exactly.

Man 2: I did not know we could do that with a WODynamicElement.

It's a very important distinction to make, because it can affect certain things when you think about stuff. You think about a car, you think about the wheels. Normally, you'd put the wheels...I'm going to get too tongue twisted. I don't need to. I'm sorry. Back track. I can't articulate what I want to say. But it's different. When I program in C side and Small Talk it's the opposite.

The components always know what their children are. Whereas, with WebObjects, you only know what your parent is. In this one case, it's a little bit different. Something to reflect a little bit more on. But I can't articulate myself right now.

Johann: Maybe you can do the next dynamic elements presentation next year. Follow up on that metaphor you were trying to reach.

Man 4: Thanks for your presentation. Not to get too specific, but right at the end, you were talking about the possibility for checking if the right number of children were present. Was that after processing? Also, we can talk about it later, if you want, if it's too specific.

Johann: If you're doing it in the final state of the example, where the children elements increment the counter, of course, you only have the final value at the end. So there you would have to put the validation at the end of the rendering of the list component. But if you would go the way to look at the children recursively, you could prevent the [indecipherable 0:59:18] generation of the output before.

So it depends. If you know, "OK. That component will have a very simple element tree within," you're fine going with recursive traversal. I hope I didn't lose you. [laughs]

Man 3: Hi. I don't know if this is element-related or not, exactly. But let's say you have a component that you're building up and there's a condition in there that says, "I want to put this content that's a Google Ads tag, something like that." And with the Google Ads tag, you have to include the JavaScript library at the top. But if the condition says you only show it in certain conditions...

Let's say if the user says, "Oh, I like my site ad free." So you don't want to include the JavaScript at the top. Is there a way to go and have that conditionalized, if the component is added, that child, or not? Something like that.

Johann: You can do that. Actually, the sub-class, Ajax dynamic element, comes with help methods to include scripts and CSS within the head. I chose to not include them in ERXDynamicElement. Because the normal case, as in components, you don't do that. But of course you can call ERX response [indecipherable 1:01:06] . Yeah.