ASP.NET adventure SignalR (Part 2)

Now that I have a running application that is, actually, a website based on MVC, I feel something strange. I wanted something like a classic web service, but instead, I got a bunch of pages, controllers and some generic classes to setup SignalR Confused smile

Is that necessary? I think I’m taking my eye off my goal! I didn’t even want a website.

Hopefully somebody will help me. What would I do without Internet and my friends on Twitter, LinkedIn, Skype… ??

Just to keep myself on track:

From the beginning I tried to make a “hello world”-like application. Something to get me into the business. To be more specific, I thought of an (very simple, of course) application that consist of about a server a clients (pretty common!)

  • The server accepts a number of clients.
  • After a client is connected, the server keeps sending a text message every t seconds. For example, every 5 seconds, it sends a message “Hi, client n”.
  • When the client receives the message, it should just show it on the screen.

To make it even better, I thought of making a Windows Phone 8 client.

What should I do, starting from the latest post on the matter, in order to get both server an client?

Anuncios

Modelo inusual: Núcleo de la composición contendor/contenido.

¡Saludos, ávidos reventadores de teclados!

Después de consultarlo con algunos krakens de la escena y ser guiado por ellos he decidido ponerme manos a la obra y darle al diseñador de diagramas para ilustrar lo que creo que me han contado. Y parece ser que el núcleo de la composición es esto.

ClassDiagram1

Aunque como mis facultades están a nivel de 2 de Agosto, tullido mentalmente y con hambre de bollos, puede que se me esté escapando la esencia de lo que me han contado (¡que soy muy torpe a veces!).

De esta manera podríamos tener el mismo elemento en varios contenedores, de manera que podríamos escribir el siguiente código:


        public void AddTwoRelationsForTheSameObject()
        {
            var element = new ComposableElement { Name = "Element1"};

            var rel1 = new Emplacement { Left = 0, Top = 0, Target = element };
            var rel2 = new Emplacement { Left = 20, Top = 10, Target = element };

            element.Contents.Add(rel1);
            element.Contents.Add(rel2);
        }

Como podéis ver, los elementos no poseen de forma intrínseca unas coordenadas, sino que la relación (Emplacement) es quien completa esos datos del modelo.

El problema que publiqué ayer podría empezar con algo así, ¿qué os parece? ¿Errado o fetén?

Caso de un modelo inusual: Elementos relacionados con la presentación.

¿Qué pasa, chavales? A pesar de que normalmente no me lee ni el Tato, ayer mantenía una “conversación” por Twitter, dentro de lo puede ser una conversación en Twitter, con @XaviPaper y con @gulnor. Era sobre un modelo un tanto raro que incluye objetos que normalmente estarían representados directamente en la interfaz gráfica de usuario y no en el modelo. En este caso, los elementos gráficos SON EL MODELO. Se presenta, pues, un problema un tanto atípico. Fundamentalmente, las relaciones son de contenedor/contenido y lo primero en lo que he pensado es en un patrón Composite que incluya a la mayoría de elementos del modelo. También es interesante el tema de que la estructura no es un árbol, sino un grafo. Algunos elementos especiales (formularios) pueden tener más de un padre.

Aquí va todo el enunciado con la descripción completa del problema.

ABSTRACTO

En mis ratos en casa estoy construyendo una especie de maquetador de formularios dinámicos. ​​​​El usuario puede añadir elementos a un formulario, arrastrarlos a diferentes posiciones, redimensionarlos y cambiar sus propiedades. Llegado el momento, el usuario decidirá “renderizar” el formulario y donde corresponda, los elementos del formulario que son dinámicos (campos) tomarán un valor “real” formulario de acuerdo con una fuente de datos (sea un XML, una tabla de una base de datos, un archivo CSV…). Esto sería algo similar a lo que hacen los Bindings en XAML.

He estado dándole vueltas al coco para hacer un modelo flexible, elegante y que “hable” por sí mismo.

He probado varias cosas y no me acaban de convencer. O bien es demasiado restrictivo o demasiado permisivo. T​e​n​g​o​ ​u​n​ ​p​a​r​ ​d​e​ ​prototipos actualmente, pero he decidido no seguir adelante porque la implementación y el modelo empiezan a no casar como me gustaría.

El dominio es un documento destinado a la presentación/impresión, con la particularidad de que habrá partes dinámicas que dependerán de una fuente de datos (por ejemplo, un XML, un archivo de texto o una base de datos).

Podéis imaginar que es un PDF que acepta una fuente de datos “externa” y renderiza el contenido dependiendo de la misma. Si dentro del documento existe un campo que hace referencia a un dato llamado “NombreUsuario”, en el proceso de renderizado, el campo tomará el valor de esa variable y en el campo podrá, por ejemplo “Pepito López”.

ESPECIFICACIONES

Un documento está compuesto de páginas. El tamaño de las páginas es un tamaño estático (ancho x alto). El usuario podrá cambiar el tamaño de la página, pero no estará enlazada con datos (al contrario que los campos dinámicos).

Una página (formulario) está compuesta otros elementos que pueden ser:

  1. Formas (rectángulos, líneas, elipses…). No tienen ningún tipo de dinamismo.
  2. Campos dinámicos: textos. Se enlazan a una variable y se reemplaza al renderizarse.
  3. Imágenes dinámicas: Imágenes. De acuerdo a un token (o ruta de acceso) se pone una imagen u otra.​
  4. Textos fijos.
  5. Elementos compuestos.
  6. Tablas
    1. Tablas cuyos elementos son generados dinámicamente: se sabe el número de columnas, pero no el número de filas.
    2. Tablas cuyos elementos (m x n) se conocen, aunque su contenido puede ser variable.
    3. COMPOSICIÓN: Podrán tener imágenes, texto, campos ¡u otras tablas! Es más puro estilo tablas embebidas de Word o HTML
  7. Gráficos estadísticos
    1. El valor de las variables es dinámico
  8. Secciones (COMPOSICIÓN). Es una especie de contenedor cuyo contenido, además de elementos de su mismo tipo, puede contener todos los anteriores.
  9. El tamaño de una sección es el tamaño que ocupen sus elementos hijo.

Todos los elementos tienen ancho y un alto. La manera de indicar la posición que ocuparán en la página es mediante coordenadas absolutas respecto al punto superior izquierdo de su contenedor.

NOTA. Una sección puede estar contenida en varias páginas o en varias secciones. Es decir, si la página 1 y la 2 comparten la misma sección y la modificamos, el cambio se reflejará en ambas páginas. A la hora de componer una sección a base de otras, la restricción será que una sección no podrá contenerse a sí misma, recursivamente.

Los elementos compuestos me vuelven un poco loco, porque son bastante dinámicos. Por ejemplo, en el caso de una tabla, no solamente las filas se generan de acuerdo a la fuente de datos, sino que los elementos de cada columna son dinámicos ​​​y además hay composición (recursivamente una celda de una tabla puede contener una tabla u otro elemento complejo).

También el tema de la composición de elementos, dudo en cómo se podría hacer.

¿Qué opináis, lobos de mar? ¿Es todo tan jodido como parece? ¿Tengo que hacerme un sistema de layout de doble pasada como el de  WPF para solucionar el tema?

Espero que opinéis 😀 ¿Alguna propuesta?

Más adelante trataré de poner algún diagrama de los que he estado haciendo.

ViewModels: make them right!

It’s not so simple to just make a class implement the INotifyPropertyChanged and create some properties.

Normally you have to REPRESENT a model. But how? Replicating the properties in the model that you want? Exposing the model itself using a property?

That is a good question that every MVVM lover should have asked himself when writhing a ViewModel.

You can take a look at this article. It really hits the nail on the head.

http://msdn.microsoft.com/en-us/magazine/ff798279.aspx

I normally expose the model directly and make UI classes that implement INotifyPropertyChanged. But I see the property mapping far more elegant and pure MVVMish 😉

What do you prefer?

Handling selected items in a parent. Part 2.

Last time I tried to put you down to the problem: you have a container and some children. We wanted to handle the selection of items.

Until now we had to decide who will be the one that is in charge of setting the IsSelected property of each child. At first glance, we can see that the child itself is the Information Expert in which we can delegate the responsibility. After all, the children carry the  IsSelected property!

Well, I think it’s true, but that makes the design unnecessarily complex.

Why?

Imagine a Single selection mode! Just like ListBoxes have. Just one item can be selected.

I gave you a hint in the last post. It works as you should expect: Each click in a child selects it, but it also makes the previous children to be unselected.

“Wow, boy, it sounds pretty simple!”

I prepared you for the answer: it’s not the child that controls its IsSelected property… it’s the PARENT! In my opinion, it’s the only that can observe the changes and control the flow of events. If a child is clicked, the parent must know. Why? Because the it can decide if the change is allowed of not.

What way, you can even have some selection modes. For example, you can have a selection mode that toggles selection when a child when it’s clicked, or one in which you always add items.

In other words, it gives you a lot of variants to choose.

This is what I finally chose in my personal designer and I think it’s the right decision. What do you think? would you have solved the situation like me? Sonrisa C’MON tell me.

Handling selected items in a parent. Part 1.

When trying to make a good design you face situations in which you have to take a difficult decision that will easily affect the whole complexity of any  further development.

“Design concerns”. That is how I call them. And some are really nasty!

From now on, I will share the troubles I stumble upon. Because not only will I annotate my current design concerns for future self-reference, but also let people participate with comments.

One of my current design issues I ran into was the relationship that a parent and its children keep in several ways, the most important of them being the selection of children.

Let’s imagine this situation:

image

We’ve got a designer surface with some items. This surface is the parent of every other items inside.  Its children are Mario, a Button that says “Hola tío” (Hello dude), and the pretty obvious TextBox “This is my text”.

Knowing that it’s a designer with some elements into it, the user will expect some specific behavior. The most important are dragging and resizing.

Now the user sees Mario into a blue rectangle, remembers the times when they jumped all the way breaking blocks and decides “I will drag Mario!”. OK, the user expects Mario to be dragged around the surface.

STOP. Before moving anything we have to know what we want to move. How will we know that we have to move Mario?

ANSWER: Oh yes. In order to move him, we will have to select it first. So we will have some items that will be selected. Selected items! Risa A common concept, uh?

OK, that sounds good.

Selected items, but what selected items? We need to select some of the children.

HOW?

Clicking on the desired item should be enough. It’s the standard behavior. Isn’t it? So we decided that we will get the clicks on each item in order to know it has been selected to do something (dragging, for example).

Let’s go!

  1. Create a boolean IsSelected property, for the class that will represent the item.
  2. Add an event handler to each child to capture the mouse click and change its state.
  3. On click, turn the IsSelected to true.
  4. Give the element the proper appearance when it’s selected.

Pretty good.

Now, click every item and observe the goodness we achieved!

image

OK, you may have noticed that not only the items are selected individually, but also they is a concept of group in the capture. Just ignore it Sonrisa it’s part of my Glass library, currently being under development.

The fact is that we have a bunch of selected items that cannot be unselected. “Woahh, simple!” you will say. Just toggle IsSelected when clicking each time.

IsSelected = !ISelected;

Neat. Now you have more options. It’s alright. You win. But this is still far from being usable.

  1. First of all, when you have selected something and you want to drag it, each click will change the selection state.
  2. It’s really annoying to select items because most of times you will only want to select a single item: the one you just clicked. The others are discarded and only the newest should be the selected one.
    I know, I know! there will be many times in which you will want to select multiple items. We definitely will have to handle those situations.

You may ask:

– Couldn’t I just intercept clicks on an item and then iterate through the rest of children in order to unselect them? In other words: each time I click one, I can unselect the others.

WRONG! If you click an item and this item and you make it responsible for changing the state of its neighbors, you’re giving it a really high responsibility. How could it be aware of each other item? That sounds like we’re breaking some very important rule.

If we have to interact with other neighbors but we’re just a little modest item that cannot say the others what to do (we don’t mind about them), who could help us to unselect the rest of the items if I, as a child, receive a click and I want to change my state?

To be continued… Sonrisa