XML Data Storage and XmlSerializer : The easy data store

Earlier I worked in an application where the data storage was XML and we spent quite some time designing the XSD and finalising what tags will be there for storing the different data. This is quite trivial when we need to use it as a datastore and the application need to be able to get some specific data out of it or we need some query implementations on top of this data storage.

Sometime back, in a team that I was associated with, needed a small datastore for some hierarchical data. The requirement was to get the data loaded into the application right at the startup of the application and save back the changes done at the end of the application or whenever the user wish to save back.

With all natural instincts, the team started thinking of the structure of the XML and ways and means of loading the data from XML and saving the data back node by node. After some hit and trial with some POCs they reported the issue that it is becoming hard to design this structure and writing a good data access or serialisation class.

I think almost any programmer, who has not worked on XML extensively,  tend to start in this manner only. Then with some throw of light on the XmlSerializer and a slightly different angle of thought, the easy and simple solution came up. We used a .NET Collection and other data structures to create our data structure that was easy for the program. For the first time, we set some default value to the structure and simply saved it to an XML file using the XmlSerializer. The method was something like:

Voila! We have the XML file without putting any effort on the design of the XML. Thanks to XmlSerializer. Our next point was to prove that we can reuse this XML. So we needed to deserialise the XML file and get back the original data structure. So the deserialisation code:

Awesome! It worked without any glitch and the module was ready in flat 16 hours as the team had to put their effort on the business rules and UI only.

Importance of Up-Front Design or formal design discipline

Design-before-you-code is a school of thought that believes that what code is to be done (or what classes to be made and how they will interact) should be thought of and documented, reviewed looking at alternatives and also checking for the necessary and sufficient condition of fulfilling the need with probable extensibility in case of changes.

So if we see, any one who is not doing "design" before coding, must also be having these thoughts in mind while firing up the code editor and writing the classes and its methods. If someone is thinking about the classes and its interaction, it is better to follow the design discipline.

But with programming styles like agile, peer programming etc, the need for exclusive designing is decreasing in certain projects. However the product development teams that work on hardcore engineering products do follow the design discipline. The benefit is not only reduced coding time, but also maintenance of the product in long run.

People at times come up with question that "Can there be real examples citing this?". I don't know exactly how a real example be cited. But, I have experienced both the two cases. Both in two product developments. The first one was developed without the designs being made. And we saw a lot of pain during maintenance as extensibility was a big issue. The second one was following the disciplines and we felt the maintenance was quite less painful, so lot of efforts were saved.

I am yet to experiece agile or extreme programming or TDD kind of stuff and probably have not heard anyone following these for engineering product development. I shall keep my option open to experience the same.

Goal Management -Goal partitioning for Construction phase

This is the third part in continuation to my earlier post Goal Management - Goal Management - Goal partitioning for Elaboration phase

The goals that are set in the construction pahse is looking at the business goal of delivering some usable system to the end user or consumer. The goals in this phase are broadly:
 
    *  To describe the remaining requirements
    *  To flesh out the design of your system
    *  To ensure that your system meets the needs of its users and fits into your organization's overall system portfolio
    *  To complete component development and testing, including both the software product and its documentation
    *  To minimize development costs by optimizing resources
    *  To achieve adequate quality as rapidly as possible
    *  To develop useful versions of your system (alpha, beta, …)

During the Construction phase, your project team will focus on evolving the technical prototype that you developed during the Elaboration phase into the full fledged system. As a result, your team will:

    *  Achieve and maintain adequate quality in your work as early as possible
    *  Develop software models that are sufficient to guide the implementation of your system
    *  Work closely with your user community to validate that your work meets their needs
    *  Implement and test the various components of your system
    *  Develop useful versions of your system as early as is practical
    *  Baseline the validated components and
    *  Manage the risks, people, and other project resources effectively.

As you work towards your goals, you will create and/or evolve a wide variety of artifacts:

    *  Revised requirements model (use cases, supplementary specifications) describing what you intend to build
    *  Revised project−level software architecture documents (SAD)
    *  Detailed software design models showing how your system is built
    *  Executable system ready for beta release to your user community
    *  Revised project schedule, estimate, and risk list from which to manage your project
    *  Revised team environment definition (tools, processes, guidelines, standards, etc.) indicating the tools and techniques that your team will use
    *  User, support, and operations documentation that is ready to be beta tested.

Goal Management - Goal partitioning for Elaboration phase

This is the second part in continuation to my earlier post Goal Management - Goal partitioning for Inception phase

While the team identifies requirements in the inception phase and also find out the business risk of the project during the same, the elaboration phase is the time when the technical risks are supposed to be unearthed and mitigated. So definitely the goal in this phase is to elaborate the system technically. This includes:

    *  To elaborate the system's technical requirements
    *  To establish the architecture (establish different views of the system).
    *  To establish the QOS and all non-functional requirements
    *  To take judgemental approach to meet the non-functional requirements optimally
    *  To make sure that the change in the mix of the factors of non-functional requirements can be done in future
    *  To unearth any possible technical bottlenecks or hurdles (by taking up proof of concepts)

The Elaboration phase is the second of six phases -- Inception, Elaboration, Construction, Transition, Production , and Retirement -- that a system experiences throughout its complete lifecycle.  This phase has several goals:

    * To produce a proven, architectural baseline for your system
    * To evolve your requirements model to the "80% completion point"
    * To develop a coarse-grained project plan for the entire Construction phase
    * To ensure that the critical tools, processes, standards, and guidelines have been put in place for the Construction phase
    * To understand and eliminate the high-priority risks of your project

Goal Management - Goal partitioning for Inception phase

Goal Management in iterative development process is a multi step process. Starting from partitioning the goals into phases and then from phases to iterations is a critical process.

Goal partitioning into phases:

The phases are Inception, Elaboration, Construction and Transition. Now how to partition the goals of the project into these phases? Let discuss it from phase to phase:

1. Goal partitioning for Inception phase

Inception is a phase in which the team basically identifies the requirement for the system. This is the phase in which the feasibility of the project comes up. It gives insight to the complexity of requirements and possible technical challenges. So which goals are to be partitioned into this phase? The primary objective of this phase are:

    * To describe the initial requirements
    * To develop and justify the business case for the system
    * To determine the scope of your system
    * To identify the people, organizations, and external systems that will interact with your system
    * To develop an initial risk assessment, schedule, and estimate for your system
    * To develop an initial tailoring of the Unified Process to meet your exact needs

The primary goal of the Inception phase is to set a firm foundation for your project. To accomplish this, we will need to:

    *  justify both the system itself and your approach to developing/obtaining the system,
    *  describe the initial requirements for your system,
    *  determine the scope of your system,
    *  identify the people, organizations, and external systems that will interact with your system,
    *  develop an initial risk assessment, schedule, and estimate for your system, and
    *  develop an initial tailoring of the Unified Process to meet your exact needs.

So if we look at this, this phase actually adds to the goal of the project itself. It basically provides input and a base for the rest of the phases. The artifacts that might come out of this phase are:

    *  A vision document
    *  An initial requirements model (10–20% complete)
    *  An initial project glossary
    *  A business case
    *  An initial domain model (optional)
    *  An initial business model (optional)
    *  A development case describing your project's tailored software process (optional)
    *  An architectural prototype (optional)

So if we try to partition our project goals to this phase, we shall have to take up those goals that are primarily for the achievement in business functionality. But we can not take out rest of them. So we hardly partition the goals in this phase. We on the other hand give concrete form to the project goals in this phase.

Enabling mobility for enterprise application

Almost all enterprises have a physical boundary and some tangible shape for its service boundary. The enterprise do all the talkings with the market/consumers/customers staying within its peripheri. Only few enterprises like mobile or wireless phone has been able to assume the shape of an amoeba - known well for being able to take almost any shape. All this is possible because of the capability of this wireless technology. So the mobile or wireless technology is now has started giving food for thought to the enterprise technology pundits to evolve different techniques to give dynamism (or so called amoebeic boundary) to their enterprise. The keyword is Enabling Mobility. This will make the enterprise reach every nook and corner of the market/jurisdiction seamlessly and enable its stake-holders to interact at their convenience.

Let us see some scenarios:

1. Banking: Now banking system has also left their original bank branches and are available on roadsides in the form of ATM. Some of the countries has allowed the banks to establish their ATMs in the median of a high street. Most of the banks provide you their servce over the internet (some infrastructure is required here like a computer system and internet connectivity). This gives a fair level of mobility but might not be available to all socio economic sections of the society. Computer penetration is poorer than that of the mobile phone. Some banks have further penetrated and established some connectivity right inside your pocket (read your mobile phone). So definitely the mobile phone is the best choice. So the buzz word in bannking is m-banking or mobile banking.

2. Bill payments: Utilities (water or electricity), Insurance and other service companies earlier used to send you a paper bill with folio section, where you put in the details of the payment instrument (cash/cheque/bankers-cheque) and deposit to their office on some particular time slot. As time passed by, they allowed you to drop the payment in a drop box. Then came the revolution of easy-bill, where you turn up at a easy-bill outlet at your convenience. But still there is some physical boundary and a pseudo-amoebic structure. Now come the mobile, so you can use a small software downloaded to your mobile to transact and pay using your credit/debit card for the service. so the mobility is complete.

3. Indian railways also crossing the physical boundary. Now, the train ticket examiner checks your ticket and updates the system using the PDA in his/her hand. The system is updated immediately, so that updating the reservation charts in the stations ahead can be updated in accordance.


We can cite a lot of such scenarios coming up. Thinking forward we can also consider business like doing a billing on the spot. Spot-billing is already there, though the billing logic is currently simpler in such scenario or there are a lot of pre processing in this case. In the future, we might see the whole billing solution can break the boundary.

Be here after some time. There will be some new update on this...

JS Calculator

I have just created a calculator that can be invoked in a page.

Currently, the key combination for invoking the calculator is the Ctrl Windows key. This shows and hides the calculator. The calculator has a text area and the user can type in an arithmetic (Validation is pending for non arithmetic keys) expression and on enter key, the same is evaluated.

Here is the code
=============================
<html>
<head>
<script language="javascript">
document.onkeyup = KeyCheck;
var calcVisible = false;

function KeyCheck(e)
{
var KeyID = (window.event) ? event.keyCode : e.keyCode;
switch(KeyID)
{
case 91:
if (!calcVisible)
ShowCalc('CalcPlace')
else
HideCalc('CalcPlace');
break;
default:
//alert(KeyID);
}
}

function ShowCalc(ParentId)
{
var strCalcEl="<div id='calc'><textarea id='calcInput' style='width:300px; height: 50px;' onkeydown='EvalCalc(event);'></textarea><br/><input id='calcResult' type='text' readonly STYLE='width:300px;'/></div>";
document.getElementById(ParentId).innerHTML=strCalcEl;
calcVisible = true;
document.getElementById("calcInput").focus();
}

function HideCalc(ParentId)
{
document.getElementById(ParentId).innerHTML="";
calcVisible = false;
}

function EvalCalc(e)
{
var KeyID = (window.event) ? event.keyCode : e.keyCode;
switch(KeyID)
{
case 13:
document.getElementById('calcResult').value=eval(document.getElementById("calcInput").value);
break;
default:
//alert(KeyID);
}
}
</script>
</head>
<body>
<div id="CalcPlace" style="width:100%;"></div>
</body>
</html>
=============================

A-Z Guide to Being an Architect

Eh! There is something interesting to read and learn. We here also are in the way of architecting in a big way already. I am reproducing this post from MSDN.

 

A-Z Guide to Being an Architect

A Is for Advocate

“I think you’ll find that you really don’t want to do it like that.”

Architects have to explain and advise on technical issues to business stakeholders. They also have to be able to advise delivery teams on how to build. This advice is the currency of an architect; invested wisely, it will return goodwill and trust. The architect is asked for advice, because it is the architect’s job to “see the whole.”

See also: Abstraction, Agile, Acrobat, Availability, Analysis, Applications

 

B Is for Balance

“A little more to the left. Keep going. A bit more. Not that far. Sorry.”

All decisions involve trade-offs—for example, adding a security measure may hurt performance. It is the architect’s lot to make the right trade-off. Architecture may be a zero-sum game, but knowing what the system is intended to achieve enables the architect to choose the trade-offs that make the system successful. Of course, where there are competing objectives, it falls to the architect to explain the issue and seek resolution through prioritization of the objectives.

See also: Best Practice, Benchmarks, Building Blocks

 

C Is for Coach

“Work through the pain!”

With so many choices for the implementation of a solution, architects cannot simply dictate to development teams their notion of the “architecture.” They are now called upon to coach development teams. Softer skills are needed: asking how and why rather than instructing “do this” and “do that.” This is a Good Thing. Development teams who understand the reasons for the architecture are more likely to commit to it and are likely to do a better job of implementing it. Architects can also begin to spot talent within development teams and offer useful career progression opportunities.

See also: Communication, Champion, Context, Collaboration, C#

 

D Is for Dependencies

“What happens if I unplug this? Oh!”

The relationships among the components that make up anarchitecture are of fundamental importance. Dependencies are inevitable but should be as few and as manageable as possible. Draw a diagram and map the dependencies. Circles, whether direct (A depends on B and vice versa) or indirect (A depends on B which depends on C which depends on A) are a Bad Thing. If many things depend on D, then D needs to be stable because changing it will have a significant effect.

See also: Design, Development, Delivery, Domain, Documentation

 

E Is for Evangelist

“Let me show you something really cool.”

Architects need to be advocates for the choices they have made; others need to believe in the ideas, frameworks, and guiding values of an architecture. Evangelism is about telling stories to different people. A simple segmentation may be a technical versus business audience, but there are really many differing audiences within that. The architecture needs to have a compelling story for each. An evangelist is able to synthesize and simplify complex scenarios for the benefit of common understanding.

See also: Enterprise, Engineer, Enthusiast

 

F Is for Frameworks

“How do I get there?”

Creating the architecture for a solution may be difficult. Creating the architecture for multiple solutions is harder—especially, given time pressures and the integration between solutions. An architecture framework is a structure that removes some of the wheel reinvention that would otherwise occur. It provides tools, methods, and a common vocabulary for the process of creating an architecture. An architecture framework can be considered to address the how of architecture.

See also: Facts, Functionality, F#, Firewall

 

G Is for Governance

“It is the opinion of the subcommittee…”

There comes a time, as they say, when you have to put on the suit if you’re serious about doing business. Control is an important part of realizing an architectural vision. Regardless of the model of IT—centralized, decentralized, or federated—there will be competing requirements of equal value. A good architecture needs to be able to flex to differing needs, but not so much that the values of the architecture are lost to the immediate, possibly short-term, must-haves of the business. Equally, good governance can give a positive, dashboard-style view on technology for the business. Common understanding is always a Good Thing.

See also: Generative Programming, Generalist

 

H Is for Human Dynamics

“The system would have been a success if it hadn’t been for those pesky users!”

Understanding how people interact with each other and the systems that support them is crucial to delivering successful solutions. The dynamics of each project and team will be different; the stakeholders’ relationships and motivations may be unique to a given project. Knowing how to navigate human relationships is a key skill of good architects and good leaders.

See also: Heterogeneous Environments, Heated Debates, High Performance Computing

 

I Is for Innovation

“The lifeblood of any organization”

Most products can be viewed as a cycle of invention, innovation, commoditization, and redundancy. Invention is costly, slow, and can require luck and big leaps in thinking. By commoditization time, the game is up, and harnessing the work of others is probably the best option. Typically, therefore, it is the innovation space where advantages—efficiency, competitive differentiation, and so forth—can be achieved through perhaps smaller, but no less valuable evolutions and revolutions of existing ideas and solutions. Small teams can push for innovation constantly and take chances to make their name. Larger groups and organizations may not be able to move as quickly, but they need to enable innovation to percolate from individuals and teams and develop mechanisms for making the best of this inspiration and imagination. Architects can be the mouthpiece for the technical teams, and the ears of the business for innovation.

See also: Integrity, Inspiration, Infrastructure

 

J Is for Judgment

“With great power comes great responsibility.”

When the discussion is done and a technical decision must be made, then an architect is going to have to exercise judgment. The team entrusts the architect to make these judgment calls, and the architect’s good judgment gives confidence to the team. For better or for worse, a series of good or bad calls may be seen to characterize the architect: conservative or wise, impulsive or prescient, biased or brave. Exercising good judgment is vital, but in practice, even good judgment will sometimes turn out to be wrong. Don’t worry about making a mistake; worry more about not doing anything.

See also: Java, Just In Time

 

K Is for Knowledge

“If only I knew then what I know now.”

Knowledge is a key architectural tool. Of course, being aware of the boundaries of your knowledge is a Good Thing. Areas that are known unknowns are ripe for proof-of-concepts and other knowledge-building exercises. Unknown unknowns, on the other hand, are Bad Things: They are the architectural equivalent of gremlins. Knowledge of technology is only one, albeit important, domain that an architect needs to command. An architect also needs to know about the nontechnical factors that will be in play, such as organizational structures, enterprise strategy, business processes, and development methodologies.

See also: Kernel, Keyboard

 

L Is for Leadership

“I’m behind you all the way.”

Leadership is vital for an architect and typically takes two forms: thought leadership and team leadership. As guardian of the architecture and the values behind the architecture, the architect is thought leader: The architect continually reevaluates the vision and re-presents the “newer, shinier” vision, with comment on competing visions and emerging technology. As team leader, an architect may not be required to perform line management duties, but may be called upon to be an icon for the rest of the team, providing confidence, insight, motivation, and inspiration.

See also: Lean, Linux, Latency, Load Balancing

 

M Is for Modeling

“So, to help us visualize how this might work, I made this model using nothing but twigs and guitar strings.”

A model is a representation of something—for example, a business process or computer system. Views of a model provide a way to communicate and understand ideas about the problem and the solution. Different views address different concerns—overloading one view in an attempt to address multiple concerns will either lead to an overcomplicated view or an oversimplified understanding. Having a shared notation for representing these views of a model can simplify conversations about the model—although, if the notation becomes too complex, this benefit is soon lost.

See also: Management, Maintainability, Messaging

 

N Is for “N-tier”

“A house of cards”

Data Layer, Business Logic Layer, User-Interface Layer. Job done. Well, not quite. N-tier is a vague term at best, and doesn’t really say anything more than pointing to the idea that there should be some kind of separation of concerns between various chunks of code. With Service-Oriented Architecture (SOA), and, most recently, the explosion in cloud services—either as back end (cloud storage for example) or front end (such as Facebook)—actually describing the architecture can be harder than building it. We’re fans of the “Petri dish” approach: concentric circles usually containing square boxes as if suspended in agar jelly.

See also: Needs, Networks, Nonfunctional Requirements, .NET

 

O Is for Object Orientation

“Encapsulate this!”

Object Orientation (OO) is a programming paradigm that rose to prominence in the 1990s. It can be thought of as a way to conquer complexity by dividing a big problem or program into bite-size, digestible, and, of course, logically coherent chunks. Object orientation is often referred to as OO and sometimes as OOP (Object-Oriented Programming), which is only a letter away from sounding like a mistake. To ensure acronym coverage, we must also mention OOAD (Object-Oriented Analysis and Design). Object orientation is as much an analysis technique as it is a programming paradigm, although translation is often required from an analysis, or conceptual, model to a design, or logical, model—just as there is between the design model and the implementation, or physical, model. An object—the entity at the core of OO—has both behavior and data, and the functionality of a system is achieved through the interaction of objects. Objects, which are instances of classes, expose their abilities via methods. There are, predictably, some key concepts and terms to be learned in order to grasp OO—the most important being inheritance, polymorphism, encapsulation, and abstraction.

See also: Operations, Object-Relational Mapping, Operating System, OLAP

 

P Is for Patterns

“I think I see something emerging from the chaos. Is it a zebra?”

Patterns are everywhere it seems. Where there was the Gang of Four and their original Design Patterns, now there are many resources and books dedicated to patterns across many disciplines. Some are stronger than others and probably some judicious pattern-weeding is necessary for a well-maintained architectural garden. Patterns provide both a template for the implementation of a particular concept but also a common language to discuss abstract and complex concepts without the need to resort to a full description, or a diagram—although we’d probably do that, too.

See also: Principles, Platforms, Politics, Performance, Process

 

Q Is for Quality

“Good enough isn’t good enough.”

Quality is often understood as a synonym for good. Good is hard to define and measure. Quality should be defined and measurable. What quality is really about is ensuring that the solution meets the requirements and all the applicable standards (as defined by the enterprise, industry, statutory authority, and so forth). By defining and specifying the metrics and standards, a solution can be judged—and, if necessary, improved.

See also: Qualifications, Queries, Quantification, Quantum Computing

 

R Is for Road Maps

“You take the high road, and I’ll take the low road.”

Where architecture and real life sometimes come unstuck is in the difference in times between the production of concepts and the subsequent realization of the vision. Many obstacles stand in the way of a beautiful architecture: differing views, changing product strategy, short-term tactical needs. A road map can help to maintain the original vision, providing a view on the now, the soon and the later of the implementation. A road map can provide the business with a view on the plans and targets of the technology teams. A road map can sometimes help you remember just what it was that you were trying to do in the first place.

See also: Requirements, Realization

 

S Is for Strategy

“What are we trying to achieve?”

Strategy sets out how to achieve your goals. Architectural strategy is derived from the enterprise strategy—it should enable the enterprise to achieve its goals. The word “strategic” should be used with care and caution—many before you have used it to justify costly, long-term investments with ill-defined benefits. A strategy, like a good military plan, should be adaptable—otherwise, it will collapse upon contact with reality. Strategy is often confused with—and sometimes mistakenly thought to be in opposition to—tactics. Tactics are the specific actions that, by achieving objectives, are the implementation of your strategy.

See also: Services, Software, Standards, Security, Scalability

 

T Is for Thinking

“I think, therefore, I clearly have too much time on my hands.”

As a skill, thinking is typically not a problem for developers and architects. Finding the space and time to think is a little harder. In these days of a constant bombardment of information from the blogosphere—good, bad, and ugly—it can sometimes be hard to find the inclination to think for oneself. Such a crucial activity needs to be given focus and an architect should be prepared to make the space and time and defend it. Think about thinking: What works for you? Long train journeys? Music? A hot bubble bath? It might be hard to install a bathroom suite in the office, but you never know.

See also: Technology, Transparency

 

U Is for Understanding

“I do believe you’ve got it.”

Understanding is complementary to knowledge. Understanding people, systems, and processes makes a significant difference to the outcome of a solution. It is the antithesis of assumption. Some nefarious types will present assumption as understanding; this is undoubtedly a Bad Thing and will not lead to the Promised Land of Good Architecture. Questioning is a key technique for reaching understanding; used well, it can puncture assumption, myth, and other forces that could derail a project.

See also: UML, Unix

 

V Is for Values

“Explain to me again why we’re doing this…”

The values of an architecture are best expressed as principles—the value system that guides decision-making and architectural practice is made up of these values. Principles are, therefore, the foundation that underlies architecture. To be effective there should be no more than a handful of enterprise-level principles and they must have the support of senior leaders. A good principle is clear, consistent, relevant, appropriately focused, adaptable, and stable.

See also: Virtualization, Visualization, Views

 

W Is for Whiteboard

“It’s probably easier if I just draw a picture.”

Good whiteboarding skills are a true art: It is easy to become an apprentice, but achieving mastery is always elusive. On the evidence of our own careers, we suspect that many great ideas have never been implemented simply because of a “bad gig” on the whiteboard. In the future, if the original pioneers of computer technology are to be remembered (that’s you, by the way) then the most fitting monument would be a huge statue of a whiteboard in pristine white marble, with just a few tell-tale signs of the accidental use of a permanent marker.

See also: Workflow, Wikis, Windows, Web

 

X Is for XML

“<xs:element name=’quote’ type=’xs:string’ />”

XML has become a universal markup language; thus, providing a nonproprietary format for data storage and a means to integrate systems and applications. While it has its detractors and there are rival markup languages (such as JSON and YAML), there is, as yet, nothing that can rival the reach of XML. While some may think of XML as the Esperanto of the Web, it is really nothing more than the basis for a shared language. Think of XML as providing the letters and the punctuation, but not the words or grammar. XML Schema (XSD) provides a means of defining XML documents that can be shared and used to validate documents. And, while there are alternatives, such as RelaxNG, XSD—like XML—has sufficiently broad reach that it is likely to be understood by partners and customers.

See also: XSD, XPath, XQuery, XAML, XOML

 

Y Is for YAGNI

“Stay on target! Stay on target!”

Great designs are often not grand designs. Using good judgment to decide when to build new features, or reuse prior work, or skip the features is all part of the architectural game. Still, it can be appealing to keep just building new stuff, just in case it’s needed in the future, because “you never know.” Of course, you do know; not much software lasts for all that long these days, owing to new techniques, channels, and even languages that can be exploited. If you’re not sure, more than likely, You Ain’t Gonna Need It.

See also: YAML, Yottabyte

 

Z Is for Zeitgeist

“All the cool people are doing it.”

Zeitgeist or “spirit of the age” is an important aspect of thinking and values and leadership. It’s magnified with the rate at which “ages” manifest themselves. We’re already on Web 2.0 after all. Understanding how to react to the zeitgeist ensures that the right steps are taken to respond to changing circumstance: “Let’s reinvent ourselves as Facebook tomorrow.” Typically, for an architect, it is not so much the manifestation of new thought—those are just implementations—as the underlying memes and their importance in the technology landscape. Everyone else sees “social networking,” where an architect sees “the semantic Web.”

See also: Zeal, Zettabyte, Zero Day Exploit

 

Using TreeView inside AJAX UpdatePanel

Microsoft does not support TreeView Control inside AJAX:UpdatePanel. So there are lots of issues if one need to do the same. One of my teams needed to use the TreeView inside the UpdatePanel. The core of the application is around some hierarchical documentation. As the user interaction with the system mostly through this hierarchical data, TreeView with check boxes is the most obvious selection. However, the pain began as the development progressed and changes in requirements started pouring in. One option was for clientside population of treeview. But some dynamic changes happening to the underlying hierarchical data (by concurrent users), we needed to repopulate the tree from the database. With growing data volume, clientside population had to be abandoned. But the TreeView started giving endless sitting with the code as it started behaving weirdly at most of the times.

Here are some of the key issues and resolutions of some of them. Some are yet to be resolved, however.

1. The SelectedNode property is lost in successive postbacks. The scenario is easy. Click any TreeNode. In the coddebehind, you get the TreeView.SelectedNode. But on any successive postback where the postback is caused by anything other than a TreeNode click, the SelectedNode property is NULL.

Resolution: Use your own ViewState to manage. Following is the code segment:

2. The CheckedNodes collection is null in successive postbacks. The scenario is easy. Check any checkbox associated with a TreeNode. In the coddebehind, you get the TreeView.CheckedNodes collection. But on any successive postback where there is no change in the checkedNodes, the CheckedNodes collection returns 0 count. And in this point of time, though the TreeNodes are checked at the client (browser), a FindNode at times fail to locate the node and if it locates, the TreeNode.Checked property is also at times false. It was a nightmare to continue with such a piece of code. Thought of using the same method as that used for persisting the SelectedNode. There are issues with that. So we relied upon Session variable. Here is the code segment for the same:

3. SelectedNodeChanged event does not fire! The usage scenario include change of one node from one parent to another parent node. So what happens is that once we complete the task, we clear the nodes of the tree [TreeView.Nodes.clear()] and rebind the tree. We bind the tree to the first level only and set the nodes to PopulateOnDemand=true for the nodes that have child nodes. At this moment, if we again click on any tree node, at times it does not fire any postback. Rather the element just vanishes(?) from the treeview. If I reload the page, we can see the element at it works fine. To get rid of this issue, I use to reload the page at the end of certain usage scenario. But the pain is how to let the user know the satus of what happened at the end of the usage? Again the use of Session variable. What we have done is shown below:

At the end of any such usage scenario, put the message to the user in a session variable and reload the page:

At the load of the page, check for the existence of any session variable for pending tasks and complete accordingly:

I am aware that the methods applied are not good, rather I shall say not at all meaningful from programming point of view. But till Microsoft does not provide better solutions or I migrate to some other wiser control that works properly, these are some work arounds that we are sticking to. I shall request you to provide your valuable feedback and further suggestions on this.

 

 

TreeView inside UpdatePanel issue - postbacks on check and uncheck of the node's Checkbox

Problem: In ASP.NET TreeView control, user wish to select one or many treenodes and wish to have options for further working depending upon the selection. The selection is done using a checkbox. On checking, the server side code need to know what has been checked and provides further options for the same. The checkbox check/uncheck does not fire a postback. Though we tried to imitate the same using javascript, the page gets refreshed. We used AJAX and put the TreeView control inside an UpdatePanel


Findings:


Microsoft does not support this. An issue/request for the feature was put on Microsoft feedback site and the same has been rejected. The status of the request is “Closed (Won’t fix)”. For details see [http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=103865]


I tried following options:

1. Add a ajvascript to do a postback: I added a onClick script to the tree as follows:

        function TreeClicked()
        {
              var curevent = event;
              if(curevent.srcElement.type=="checkbox")
                {
                  //__doPostBack('','');
                  //__doPostBack('mytree','');
                  //__doPostBack('LinkButton1','');
                }
        }


It works in normal scenario. But it refreshes/reloads the page all the time. I needed a flicker free refresh using AJAX. But could not get it. This can be used if you have no issue with the page reload.


2. Derve your own treeview: I derived the treeview and created my own treeview control where I added the postback event and override the render method. This behaves very weird in Visual Studio 2005. However I got partial success in Visual Studio 2008.  
 
The cod e for deriving is as follows:

 

using System;
using System.Text;
using System.Data;
using ASP = System.Web.UI.WebControls;
using System.Web.UI;
using System.IO;

namespace MyTreeView
{
    [ToolboxData("<{0}:MyTreeView runat=server></{0}:MyTreeView>")]
    public class MyTreeView : ASP.TreeView, IPostBackEventHandler
    {
        public event EventHandler CheckClick;

        protected override void Render(HtmlTextWriter writer)
        {
            StringBuilder builder = new StringBuilder();

            using(StringWriter stringWriter = new StringWriter(builder))
            {
                HtmlTextWriter tempWriter = new HtmlTextWriter(stringWriter);
                base.Render(tempWriter);
            }

            string find = "<input type=\"checkbox\"";
            string replace = "<input type=\"checkbox\" onclick=" + getPostBack() + " \"";

            writer.Write(builder.ToString().Replace(find, replace));
        }

        protected override void RenderChildren(HtmlTextWriter writer)
        {
            StringBuilder builder = new StringBuilder();

            using (StringWriter stringWriter = new StringWriter(builder))
            {
                HtmlTextWriter tempWriter = new HtmlTextWriter(stringWriter);
                base.RenderChildren(tempWriter);
            }

            string find = "<input type=\"checkbox\"";
            string replace = "<input type=\"checkbox\" onclick=" + getPostBack() + " \"";

            writer.Write(builder.ToString().Replace(find, replace));
        }

        protected string getPostBack()
        {
            return this.Page.ClientScript.GetPostBackEventReference(this, "@CheckPostBack");
        }

        protected virtual void OnCheckClick(EventArgs e)
        {
            if (CheckClick != null) CheckClick(this, e);
        }

        void IPostBackEventHandler.RaisePostBackEvent(string eventArgument)
        {
            OnCheckClick(new EventArgs());
        }
    }
}


Work around: I thought of a work around. The user needs the checkbox only when the user needs to select more than one element. So, the user will select the element (while selecting a single one) by clicking the tree node and NOT BY CHECKING the checkbox. The options for single element selection will be provided on selection of the element by clicking the tree node. The options now being provided on multiple selection will be available all the time. If the user selects any such option where one or more check box need to be checked, the system will give a message to the user.
 

Resolution: Looking at the findings, I thought of taking up the work around as of now.