Post navigation

Do we need third-party Flex frameworks?

This started as a Skype chat room conversation between my colleague Anatole Tartakovsky and myself, and I though that it would be a good idea to invite more Flex developers to this discussion.

Having said this, I’d like to make it clear that over my career, I’ve been developing frameworks myself and truly respect people who are capable of creating frameworks and Anatole has huge experience in this area as well. Here we’re just questioning the need to create frameworks not for a general purpose language like Java, but for a domain-specific framework like Flex.

This is our dialog with minor editing. Your input and feedback are greatly appreciated.

Yakov. Why people design Flex frameworks as opposed to reusable components? One of the framework is called Cairngorm, the other one is called PureMVC. I’m sure there is more. It seems to me that such frameworks is unnecessary overhead over well designed Flex framework. Are there any benefits here? Why bother creating all these singleton-based bottlenecks?

Anatole. First of all, PureMVC seems to be more of an ActionScript Framework. It is not specifically Flex framework and concentrates on the task of creating generic a framework for low-level AS objects. Flex comes with “pre-built suggestions” of how a model/view controller might work – and it offers lots of hooks throughout the data and UI classes that help implementing MVC.
PureMVC is also “server-agnostic”. Flex made very efficient Java implementation of distributed Model that can provide dynamics to the distributed Web applications.
PureMVC is more about making apps in more traditional way.
Cairngorm was started as “Micro – Architecture” – a set of patterns that allowed solving certain problems in the application design – like Model Locator or Commands – and certain applications. It never appealed to me as it had a number of assumptions that required more coding. At best you would use one or two patterns implementation from Cairngorm, but it’s much easier to rip out the part you need and adjust it to your liking.

Yakov. I can appreciate the fact that design patterns are useful in general, because they may help developers in dealing with repeating patterns in software construction such as Singleton, Mediator, Model-View-Controller and the like. But when I look at some of the third-party frameworks built on top of Flex, I keep asking myself the same question, “Why build a framework on top of framework? Are there any benefits to introducing a middleman between an application’s views and already existing Flex framework?

Anatole. It depends on the application you are building. Frameworks provide higher level of automation and abstraction for specific tasks and with various coding and performance costs. Fo example, Flex framework has Data Management Services for distributed Web applications. However, this model has limited applicability for simple Web applications working with HTTP forms-based backend API. You’d need a symmetrical MVC API on the client side. You can also have a client-side only text editor application, for example, that is completely “out of scope” for Flex framework but would benefit from implementing a Command pattern. The real question is to identify the functionality you need, and then to see how it is implemented in the appropriate framework

Yakov. I looked at the Cairngorm’s design, and having hard times figuring out why would I need something like this? Ok, you may say that it helps to organize your project better. What else? Without any disrespect to creators of Cairngorm, I can’t find a justification to recommending it to my clients. One of them has invited me to lead an ongoing Flex project, which is being developed by a large team of developers. The project uses Cairngorm, and at the same time it consists of a number of modules. After reviewing the project, I’ve recommended to stop using Cairngorm. Without going into details, these are some of my concerns in this case:
The client wants to use modules, which are can be loadable/unloadable. But since you are forced to use Cairngorm’s singleton model locator, it’ll keep the hard references to the modules (event listeners), which won’t allow you unloading modules. So, on top of Flex modules’ memory leaking (yes, they leak), we’d introduce another memory issue.

Anatole. In many cases, a detailed look at the implementation will either get you on board or will remove the framework as not applicable implementation. In later releases of Cairngorm you can have weak references – so it works – at least theoretically. However, with modules there are quite a few places when unloading will become impossible due to legitimate code generated by framework. In general, if you are going with modules, you need multi-layered framework and intelligent registration services that are written specifically for the task.

Yakov. As far as I know, the use of Cairngorm was never approved by Adobe Flex team, but I might be wrong here. Flex framework is built on a nice distributed event-driven architecture, but Cairngorm is forcing your events to go through another singleton – event dispatcher. Why is that? Why every view has to register event listener in the central place? Now developers on a large project have to acquire additional skills in proper usage of this framework.

Anatole. The reason for use of global event listeners registration are derived from the size / type of applications the framework developers worked with. It “simplifies” the project management by providing structure and separating developers responsible for model, view and controller into separate entities. All these singletons and managers are a way to establish a non-UI but business communication between parts.

Yakov. Do we really need global areas? Why not doing it locally when needed?

Anatole. First, you need to look at the events. In most cases, these are not UI or input events but rather some application/state changes that need processing. The model is global, and the application events are defined on the global level.
I think most of the seasoned developers with UI background are uncomfortable with this approach. You might want to consider Joe Berkovitz MVCS approach as a middle ground between Cairngorm and our component-based approach that might work better for medium to large size teams that would have no access to code generators and data driven/factories-based architecture.

I recall two framework-related sessions at MAX’07, where approximately the same number of people were asked the question: how many of you have looked at Cairngorm? 70% -80% raised their hands during the Flex frameworks BOF session and 90% on the Best Practices session. During the Flex framework session people were asked a second question,“ How many of you would use or actively oppose Caingorm?“ This time they’ve got a 50/50 split.

Yakov. I hope to be able to attend MAX 2008. So all these people came to the Best Practices session to get reassured that they are doing the right thing? But I’d really want to see some concrete examples where using these frameworks would bring technical benefits. I want to stress, I’m not talking about self-contained components that would automate some tedious job but a framework on top of Flex Framework.

Anatole. I think the main benefit of any pattern library will be based on its applicability to your application. There are quite a few applications – including infamous “shopping cart” ones – that can be coded quite efficiently with any of these frameworks. On the other hand, the extra setup code provided for “flexibility” is ironically the least flexible part of it.

As far as benefit ratio between an architectural framework and smart components, I think you might want to try a little test. Ask any developer if she wants an architectural framework that still would require her to implement a DataGrid componment (she would be allowed to use Grid component or some other low level controls as a superclass). On the other hand, offer her a DataGrid component without any framework. I think this developer would recognize the importance of smart objects and go with a DataGrid. Take it a level deeper and you will see an “extra” code in a DataGrid , and we’ve successfully have overridden it in our own DataForm, SuperGrid and controls.

Yakov. Do not forget though, that we are enterprise developers and are mostly concerned with a boring thingy called data processing. There are legions of Flex developers who do not care about the DataGrid. They are into creation of cool visual components. But these guys do not need any frameworks either.

Here’s another strong statement from the PureMVC framework, “The PureMVC framework has a very narrow goal. That is to help you separate your application’s coding concerns into three discrete tiers; Model View Controller”.

But isn’t this goal already achieved in Flex Framework? Wouldn’t a simple separating views, controllers and models into different folders of your project suffice? In many cases the role of Controller in Flex is kind of blended into model itself (bindable data collections can emit and listen to events caused by some data changes). In some cases, if your application’s views have reusable business logic (i.e. validation or connection to specific back end data feed) you may create separate controller classes that may be shared by more than one view. But this should be done on the case-by-case basis, and not as a must for the entire application.

Here’s another statement from a well-written PureMVC documentation: “Making separation of Model, View and Controller interests eliminates the most harmful responsibility misplacement issues that hamper scalability and maintainability“. My English is not good enough to understand this phrase in its entirety, so can you play the PureMVC advocate and suggest, how PureMVC would improve Flex scalability and maintainability?

Anatole. Well, there is an old saying that life is a play, written by God, and directed by Devil. By making the process more formal you can build a lot smaller chunks, communicating and specific way, and in your mind the more formal process will yield better maintainability. On the other hand, it will create more parts to maintain and less flexibility to do so.

Yakov. PureMVC uses mediators, which is a very applicable pattern for the software that produces UI. But would it be that difficult for developers or project architects apply Mediator pattern while designing their business applications as opposed to relying on a framework that implements Mediator globally? Check out this blog on using the mediator. Is it that difficult so it has to be hidden into a framework?

Anatole. ActionScript 3 makes a lot of patterns excessive. A lot of things can be done by using events or dynamic code without really breaching good programming practices. One-liners work for me as long as they are simple and concise.

The main question remains, “Do you want to use intelligent objects that encapsulate most of the framework functionality or if you prefer to deal with simple objecst and do explicit coding for each instance?”

Yakov. I prefer using self-contained loosely-coupled objects.

Anatole. So, coming back to your question of system-wide singletons… I do not see any reason for creating global objects – they are really bad for both application development process and maintenance in the long run. You can have a singleton pattern inside the models themselves or bind location services with module loaders depending on the architecture of your application.

I have seen these frameworks being used mostly as means to provide project manager/architect with ability to separate areas for developers, quantify functions and make project more manageable. The effect for the resulting application most likely to be negative, but it is very straightforward approach to build systems.

Yakov. So you are saying that utilizing a framework on a project allows create and enforce a nice looking project plan that reads, “Mary will create 10 model objects by February 1, and John will be done with his views a week before?”

Anatole. Yes, and then we will have all the commands coded a week after that and then we will think about fitting it all together, essentially moving real architectural and design questions toward the end of the project. If you answer the question “How?” first, people tend not to ask “Why?” for quite some time. On the flip side, you will have people doing their parts rather quickly thus producing enormous amount of code to fix when the design problems become evident. The problem with formal coding techniques is the human generated code (thus cut/paste errors) without the ultimate understanding how it will be used and very little testing done while writing the code.

Yakov. In the USA, we are already accustomed to protective medicine, when the main goal is to ensure that the patient won’t sue you. So when a guy with a headache shows up in an emergency room, they start with sending him to an MRI and making tons of other not too necessary tests. But, it’s better to be safe then sorry… The same rationale here – it’s easier to CYA with a nice project plan (see www.acronymfinder.com for the definition of CYA).

Anatole. The problem starts MUCH later – at some point of the project the spec changes – business analyst realizes that mistakes were made, process changes, the other department needs some of your functionality or another line of business has to be handled. There is no time compression or shortcuts available there – commands need to be amended and re-coded, views redesigned, events integrated with a different workflow. You are now thinking to yourself, “Why, oh why, did not I go with an application framework instead of the architectural one?”

The application framework goal is a way to get you through the “implementation” part faster while giving you maximum flexibility on design and functionality part. If you do not have 80% of application built in 20% of the time, you will be late with the last 20%.

Flex itself is more of an application framework. It is not a library of patterns but rather a set of objects that are built to communicate and react. Flex uses code generators and other behind-the-scene techniques to achieve that. The key here is automation of implementation tasks by minimizing the amount of code while behaving predictably. That is done by explicitly checking the “related” objects for specific interfaces. By not adhering to the implementation of these interfaces, the external frameworks require serious application development effort to support them.

MVC principals are also questionable in the Web2.0 world. The concept of fine granularity and validation on the client has serious security implications. You go to any AJAX show and you see one or two sessions with security specialists, cracking AJAX sites, getting free airline tickets, buying things for one penny, etc. It seems that every serious organization should be more interested in distributed model rather then pure client side solution. In that case most of the benefits of global MVC go out of the window.

Yakov. So far we have just a couple of the third-party Flex frameworks, but creation of the new ones is a viral thing, and the last thing I want to see in Flex community is more than a hundred of frameworks that do the same thing. We already see it in the Ajax world.
Anatole, it’s not easy to quarrel when both parties share the same views. We really need other people’s opinions to better represent Flex developers who may see benefits of using frameworks.

16 thoughts on “Do we need third-party Flex frameworks?”

I don’t want to be drawn into the debate too much here. Every application has an emergent architecture, a fundamental skeleton within which the rest of the application will fit. You say that “why do people focus on frameworks rather than reusable components”, and I reiterate – the 2 are not mutually exclusive. A well designed application with Cairngorm will also incorporate reusable components.

I’ll let the rest of the community respond to your post; my thoughts are already laid out as to when you should and shouldn’t use Cairngorm, I don’t believe a black and white answer is the answer, and I’ve always took the position that if it works for you use it (and it works for many people) and that if you have preferences to use something else or something you consider more fit for purpose, then that’s a decision any good developer is capable of making on their project.

See, this is my problem: “If it works for you, use it”. What exactly should work for me? A better structured project that is easier to explain to new team members or your manager or a framework that has clear technical merits like shorter development cycle, better performance, loose coupling between components, simpler architecture? I\’d love to see a comment to this post that would state in a simple down to earth language, “We’ve used so-and-so Flex framework in a so-and-so project. We would not be able to deliver the project on time and it would not be as scalable as it is now without this framework, and these are the reasons 1….2…3….”

I’ve been doing object-oriented programming during the last fifteen years, but I’m not in love with it and would rather not see frameworks created just for the sake of OOP. But this is a whole different discussion altogether.

I’m pretty new to the Flex Arena, and I haven’t looked at PureMVC at all, but coming from the ColdFusion world, where “frameworks” have proliferated, I have a few things to add to the conversation.

As to why you would want multiple frameworks for an application (or development platform), think briefly about what a framework really is. It’s a library of pre-written code that provides services for your application, and a library of recommeded design patterns for interfacing with that library of code. Looking at things this way, the Flex Framework, isn’t so much a “framework” as a base Object Library, similar to the .Net API, or the Java API, or even the old school Win32 API. Just because we’ve applied the word “Framework” to the Flex core API doesn’t mean that we don’t need some other code or design pattern libraries to build a complete application. You can start building a .Net application using just the Windows.Forms API, but as soon as you start moving outside of the trivial applications, you’re going to start needing an architectural framework to decide how to lay out your code, and a unit-testing framework to prove that your classes are providing advertised functionality.

These frameworks aren’t being created just because someone has too much time on their hands, and can’t think of anything better to do. They’re being created because they fulfil a need. Each of them provides a service that the others don’t, or a combination of services the others don’t. You don’t (and shouldnt need to) know all of them, or use all of them, and you definitely shouldn’t be recommending them to clients or refusing to recommend them to clients. You should be familiar with what problems each of them solves, and use them when appropriate. Cairngorm isn’t suited to every single Flex Project. PureMVC isn’t suited to every single Flex projet, nor is Model Glue Flex. However, sometimes one or more of them is appropriate. Being familiar with when each is apprpriate is tough, but a worthwhile exercise.

Not all Flex developers have 15 years of enterprise development. Your article might be more well-received if you would give examples. Maybe recreate the CafeTownsend without a Flex Framework and illustrate the benefits (for you) and how where the frameworks hurt the CafeTownsend project.

Oops – comments are drifting away from the topic. Here is brief recap of what the main topic is. Steven says that you might want to build application on a certain architectural frame – there is a notion of skeleton there. In reality, it is not a skeleton of your future applications (that would be “application”* framework and not the “patterns” one) but rather set of communication patterns (outlets) and implementation classes (application bus wiring).

Yakovs point is more of “why get a cow when you can have milk for free”. Why do I need extra framework with a lot of duplicate functionality to the Flex one? Why do I have to do all manual labor of wiring and configuration instead of objects falling into places themselves and registering themselves by taking advantage of Flex built-in code generators**? Should we just treat patterns for what they really are and package them in the way we package other reusable objects? Should they be parallel framework or rather extension (or even aspect-based override) of the existing ones? Can useful patterns be that simple? Why I need global objects if I build modular application and most of my events are local? What is wrong with registration and broadcasting events via standard extensible singletons like Application?

Very few new developers think of Flex as framework. Simple fact that demos/samples work “somehow” by falling into internal communication patterns seems so natural that the question “how” is never asked. Binding, event notification and delegation are pre-built and code generated based on the tiny little metatags we place automatically – and it just works. Another loosely bind framework is CSS implementation. You place objects, apply “CSS” and the behavior/presentation chages – across multiple objects. Again – code generation and pre-built functionality work miracles. And Flex is rich with patterns that like class factories – it is foundation of the current release and becomes more profound with Flex 3 and Thermo. If you master and dynamic resources they provide solid foundation for customization and wiring in any imaginable way.

The only benefits of “structured framework” approach I can see are in the areas of project management ( well overshadowed by consequences I have seen when asked to take over failed projects – see my answers to Yakov) and some applications closely matching the ones used as testbed for the framework itself – if you think sample application does what you want to do and scope is similar – go for it. If the main reason to go with architectural framework is lack of Flex knowledge and it comes with samples/there is a lot of code – use Steven’s guiding principles “When not to use architectural framework”

Regards,
Anatole

*Application frameworks are essentially applications stripped out of some implementation details and generalized in the places that are most likely to be customized. Indeed, for your application skeleton you want something similar in size and shape – starting “fish” with “girafees” skeleton is going to be challenging at least. With a good fit though, you can have “working” app much faster – even with time for adoption and training

** Look at the compiler output to see all the initialization code Flex generated for you – why not use metatags and code generators? Hopefully, with Flex compiler going open source this week ( I believe Adobe mention end of the year in their May press release) most of our code generators can be rolled in. From the management perspective, I firmly believe that writing tons of code should be banned in most of applications.

Flex Framework has been designed and implemented as a _framework_. It is not up to us to “apply” the word framework to Flex, it’s them, the Flex team, who came with the Flex Framework by design. What I see quite often, however, is that level of training behind today’s Flex projects is far beyond the required to tap into opportunities Flex framework provides for free. One outcome of this is homegrown frameworks, which re-invent the wheel (at the very best). True, each framework fulfills the need. The grounds for this need should be questioned though. So, my point is the reasonable approach might be to start with the question: how is this design issue is _supposed_ to be addressed in FLEX FRAMEWORK? Chances are, if you ask the Flex expert, you might not need to create a “new” solution. As far as getting _familair_ with each 3rd party framework, if one can’t think of anything better to do, why not. I’d rather _study_ Flex.

I’m already into < rant > mode after wrestling through today’s second code example of Flex widget “X” that is thoroughly obfuscated by Cairngorm abstraction. I’m trying to understand how “X” works, not Cairngorm. And no, “X” isn’t at all related to the Cairngorm framework other than it’s part of a Flex project. Indeed when the example writer provides this instruction, “you’ll need to include Cairngorm.swc in your project…” then it’s clear that the author himself realizes a) Cairngorm isn’t necessary for the job at hand and b) he’s writing for an audience that doesn’t use Cairngorm. Bleh!

I grant the possibility, however remote, that Cairngorm, et al have a useful purpose but never, ever in Flex example code, unless the example is of the framework itself.

I can only agree with what Greylurk hinted at: We should be careful with the application “framework” term here. To me, flex is not a framework, it is a library of reusable components and classes, combined with a SDK. Together with the flashplayer, this makes the platform for developing applications in flash. But, it is not a framework, as I understand frameworks.

There are tons of ways to combine the library classes and tons of ways to organize the source code of flex applications. Guidance can be a good thing, which you can get from a framework. Now, I have not myself used a flex framework yet, but I will be having a look at PureMVC. Maybe I like it. Maybe I don’t. Maybe I shall then look at another. I come from a Java world filled with frameworks. Sure enough, there are some good ones, but there are also lots of not-that-great-ones (again, to me, that is).

I think it is a good thing with frameworks on top of flex (which is not an application framework in itself).

You came from a Java world that has about 50 Web frameworks, and so did I.
But I believe that Java Struts framework is bad, and when I see all these Flex frameworks that are built around MVC, it\’s clear to me that they were created by a former Java Struts programmers.

Please try to forget Struts, think more loosely coupled Spring, if you can\’t live without a framework.

Are you totally against application frameworks in the flex world, or are you simply against the ones present now? Maybe it is because there isn’t one yet, that satisfies your needs? If this is the case, maybe, by making clear (a) what you don’t like in the existing and (b) what you would like, could start a movement for a better flex framework!?

I think the Flex framework provides a lot of what a developer needs. Still there is this open ended ness to it that new developers don’t know where to start or how to architect their projects. It is much like a foundation with a wonderful toolbox and lots of “lego” pieces. Still it lacks a clear direction for some common and some obscure puzzles developers face such as global variables, singletons, etc. But these are not enough to prevent someone from finishing a application successfully.

I have to agree with Anatole that a framework can help define a structure when working on a team. To answer the question, I think a third party framework can provide structure, definition and solve some puzzles developers face but I think they are too much overhead for many projects. I do not have time. I can write something clean and precise without following a framework. What I would like to see is more structure and best practices for the existing Flex framework.

If I could sum up: people participating in discussion are confirming that flamework side of the Flex framework (and hence, structure, definition, guidance, etc.) remains hidden treasury – at lest for the unarmed eye. Certainly, that’s a subject for Adobe evangelists and training teams to address. We all should understand, however, that during the early adoption cycle deep dive into coding practices had been almost a taboo, it is so bo-o-ring for the audiences that come to see how _easy_ it is to put a gallery of pictures with transitions into a TileList. In fact, initial part of the Adobe training had been purposely avoiding coding subjects to accomodate wider range, including designers etc – and rightfully so. When you train a corporate client and talk to coders with the similar skills and background it’s a totally different story, of course. I would not be surprised if Adobe come with the course labeled Flex for developers: after all, the answers are already in the documentation, they just need to be brought up to light.

The reason I wrote PureMVC was so that people without a lot of design pattern background could be given a set of patterns and a recommended program structure that solve the MVC problem without it having to be cooked up from scratch on every application.

There’s nothing wrong with building something from scratch, just ‘doing whatever works’, but the problem is that 6 months later you yourself may not remember what you were thinking. And given the common developer’s lack of documentation discipline, it’s unlikely that ‘whatever worked’ was actually documented.

So 6 months later when a totally different developer approaches your code, if they know the framework, then they only need to understand the problem domain to make immediate progress. A quick survey of the app will show everything is in place and doing what one would expect and you get on with extending the app. This is where the case for maintainability is made.

Over the last year, I’ve looked at a lot of applications written in PureMVC by other people and – surprise – they usually look exactly as if I had written them myself. There is a lot of benefit to be had in having a well-defined methodology for the core organization of an app.

Think about where Design Patterns come from. We stole them from ACTUAL architects – people who draw up the blueprints for the buildings we live and work in. Now consider if the home you are living in were NOT architected AT ALL. The builders show up with some materials, have a look at your land and start hammering away. Depending on the skill of the builder, you might end up with something that’ll keep the rain off, but wouldn’t you feel safer in a nice well-architected house? One where all the major issues with home-dwelling had all been taken into account and handled with tried and tested methods (architectural patterns)?

Scalability is also enhanced because the way to add new use cases to the system is clear. In a system without a sound architecture, the way to add new functionality (without breaking the old) is not always so clear. To return to the un-architected house metaphor, if your house wasn’t architected, and furthermore, neither was your town, then adding new houses and getting to them would be, well, a shantytown: http://www.laputan.org/mud/mud.html#BigBallOfMud

Here’s an everyday issue with civil hacking without patterns that you’ll be familiar with.

Do you know how sometimes you walk up or down a set of stairs and they just feel wrong? You look at them and they seem well built, maybe even covered with granite, and nice little sandy footgrip pads, but still when you walk those stairs you feel weird? The step is too long or not long enough, too tall or not tall enough, somehow you stagger up and down them, cursing whoever built them. That’s because the builder / architect completely failed to apply the 7/11 Stair Pattern. Seven inches up, Eleven inches out. That’s just right for most humans and its the pattern for most stairs. Except the poorly architected ones.

I don’t agree with your shantytown analogy. I live in the area where you can find very nice looking development with buildings that look alike, but the nicest developments are those where each house was custom-built. While a framewtork allow some freedom of programming, the best result are achieved when an application uses only those building blocks that are needed for this particular application.

I can’t argue about pureMVC as I did not have a chance to use it, butwell-designed framework/class library should seemlesly blend into your application. When you look at the application’s code, you should see…the application-specific code, and not model locators, delegates, commands, etc. This is definitely not the case with Cairngorm.
I’ve joined one of my current projects too late in the game. It consists of 20 separate Flex modules and uses Cairngorm. The code looks convoluted and unnecessary heavy. I do not allow using Cairngorm for development of the new modules for this application. I’d be happy to remove Cairngorm completely, but it turned out to be an expensive project.

This is an interesting discussion.
I am a Flex newbie coming from developing in Java, .NET, C++. Like most developers I think in patterns. So using Cliff’s analogy, I think in 7/11 Stair Pattern all the time. I am given a problem and I solve it using the tools I have used on many jobs over the years – patterns. I don’t need an architect to write it on the blueprint – regardless of what is written the stair will be 7/11.
This discussion is whether you *need* frameworks when using Flex. And I have come to the conclusion that you don’t.
Before that, I endured a good few weeks trying to wrap my head around Cairngorm and coming to the conclusion that it was convoluted and felt “wierd”,(like those odd steps), cursing whoever dreamt up this unnatural way of working.
I have seen this in enterprise projects where the code becomes increasingly complex and over-engineered to comply with rules dictated by the architecture police. The end result is bloated code millions of lines long and hundreds of layers deep that is impossible to maintain. Cairngorm seems to love god-objects, reams of boilerplate code and provides unmaintainability out-of-the-box.
I doubted myself at first because I’m a newbie, and if the “experts” are using Cairngorm then it must do something and I am just missing the point. But now I am not so sure. Flex does 90% of what I need without any additional “frameworks”, and the other 10% can be delivered using standard patterns.