SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 71
  1. #26
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    Brazil,Maringá-PR
    Posts
    128
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Smile

    Quote Originally Posted by BerislavLopac
    it's just a behavior of
    I could not found a worst expression . Sorry, my fault.

    Let's stop talk and start coding.

    Here we have the kind of input I want to my calculator:
    http://neves.bs2.com.br/calc/calc.php

    It's not working, just show how the interface/view can be.
    Tomorrow, I post another three diferents views.

    What I want, is found how much code I have to write, to change my view.

  2. #27
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Sounds like what you need first is an Input / Application Controller that can dispatch based on the "key" pressed. Whether each key is a straight GET/POST or you use Ajax, you still need to process each key press.
    Christopher

  3. #28
    SitePoint Addict
    Join Date
    Apr 2004
    Location
    Melbourne
    Posts
    362
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think neves is just looking for a very simple example to show usage of MVC. The fact that it wouldn't make sense to use MVC for a calculator in the real world isn't the point. The fact that you should be able to create the same Model for both a command line and web based application is. I think he's wanting to be able to investigate how the controller and view could be swapped out for a new one to accommodate a completely different view and method for accepting user actions (even as different as a stateless or stateful applications).

    Or maybe I'm just as lost as everyone else here

  4. #29
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    Brazil,Maringá-PR
    Posts
    128
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Smile

    Quote Originally Posted by Tanus
    I think neves is just looking for a very simple example to show usage of MVC. The fact that it wouldn't make sense to use MVC for a calculator in the real world isn't the point. The fact that you should be able to create the same Model for both a command line and web based application is. I think he's wanting to be able to investigate how the controller and view could be swapped out for a new one to accommodate a completely different view and method for accepting user actions (even as different as a stateless or stateful applications).

    Or maybe I'm just as lost as everyone else here
    Many Many thanks Tanus.
    You take the words from my mind, and translated to English.
    I would like to stick your words on the first post of this thread, so everyone can read and understand what for this thread.

    Is it now clear to everyone?

  5. #30
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The fact that it wouldn't make sense to use MVC for a calculator in the real world isn't the point.
    I don't see how MVC makes any less sense than any other design strategy if you want to design a server side calculator. I can see of you said that it would make more sense to use browser based scripting such as Javascript or Flash. But how is a calculator any different than any other application.

    Sure you could build yet another PHP calculator script, but if you go the MVC route you have built something that is (hopefully) a component in a larger framework. Hence it can use other framework support such as access control, multiple views for CLI or HTML or skins or multilingual.

    The Input Controller can to input validation in a structured fashion to reduce the chance you might miss something. Building an actual model object would allow you to easily extend the calculator with other functionality. The Model could even generate and store plot data that the View could render as graphs in HTML or using GD.

    With clean separation you can unit test the thing. Important for a calculator I think.

    PHP is an ocean of scripts that don't work together. An ocean where everything is rewritten over and over in trivial variation. Some sort of framework convergence, probably MVCish, is the only slim hope for code reusablity in PHP.
    Christopher

  6. #31
    SitePoint Addict
    Join Date
    Apr 2004
    Location
    Melbourne
    Posts
    362
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    I don't see how MVC makes any less sense than any other design strategy if you want to design a server side calculator. I can see of you said that it would make more sense to use browser based scripting such as Javascript or Flash. But how is a calculator any different than any other application.
    Yep, I should have been more clear and said that it wouldn't make sense to create a full blown MVC serverside PHP application to power just a simple calculator, not that the architecture wouldn't make sense if applied in a different context. I get the feeling that neves just wants to create a simple example (to help clear up his own and others confusion of MVC) of managing user input -> processing that input -> displaying something to the user, but being able to reuse parts of that process in a completely different context (web based and cli based), ie creating a separate controller and view and using the same model. The fact that it would actually have calculator functionality is completely irrelevant.

  7. #32
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Since the purpose of the discussion is purely to illustrate layering, the calculator doesn't have to be too complex. Add and subtract will do.

    The standard way to layer an app is presentation / domain / data access. MVC finesses that by splitting presentation (UI) into controller and view. Unlike almost all web apps implementing MVC, a simple add & subtract calculator doesn't have any persistent storage which is kind of good for an MVC discussion because MVC doesn't say anything about the data access layer. It's there, underneath the model (or domain) but it's just not mentioned.

    The model would be:

    PHP Code:
          class Calculator
          
    {
              var 
    $total 0;
          
              
    /*
                  param (integer) x2 
              */
              
    function add($a$b)
              {
                  
    $this->total $a $b;
              }
              
    /*
                  param (integer) x2 
              */
              
    function subtract($a$b)
              {
                  
    $this->total $a $b;
              }
              
    /*
                  return (integer)
              */
              
    function getTotal() 
              {
                  return 
    $this->total;;
              }
          } 
    That's all the domain logic there is.

    The hard part is going to be replicating a normal calculator interface with buttons to click. There's nothing to say this can't just be a simple form though with a field for first number, second number and a check box selection of arithmetic operator.

    A controller would receive the input, identify the operation (add or subtract) manipulate the domain (instantiate a Calculator object and call a method) then tell the view to update. The calculator object would be made available to the view which would call the getTotal() method and (in html) output the value in an html template.

    The model is re-usable in other contexts such as CLI simply by replacing the controller and view. Presentation layer changes are independent of the model.

    Model changes - such as adding multiply and divide - will require corresponding changes to the controller which has new parameters to deal with (multiplication operators) and new request types to identify (multiply and divide). In this case, the view would still be calling the same getTotal method and would not change but normally you'd expect a different set of data to display after changes to the model which of course would require an edit to the view to display them. Suppose you added a memory and wanted to display the current memory value along with the rest: this would have to be added to the view.

  8. #33
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Because the calculator will be sending a value and an operation, plus passing around the current total or getting it from the session, maybe:
    PHP Code:
    class Calculator
          
    {
              var 
    $total 0;
          
              function 
    Calculator($total)
              {
                  
    $this->total $total;
              }

              
    /*
                  param (integer) x2
              */
              
    function add($a)
              {
                  
    $this->total += $a;
              }
              
    /*
                  param (integer) x2
              */
              
    function subtract($a)
              {
                  
    $this->total -= $a;
              }
              
    /*
                  return (integer)
              */
              
    function getTotal()
              {
                  return 
    $this->total;;
              }
          }

    $ds = new DataSource();
    $calculator = new Calculator($ds->getTotal()); 
    Christopher

  9. #34
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    Brazil,Maringá-PR
    Posts
    128
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

  10. #35
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:

    Can I call this up as an example when documentation (using comments) is a bad thing, and that the code itself should be self documenting?

    Two posts and the comments documentation is already wrong!

    Quote Originally Posted by arborint
    PHP Code:
    .
              
    /*
                  param (integer) x2
              */
              
    function add($a)
              {
                  
    $this->total += $a;
              } 

    Douglas
    Hello World

  11. #36
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well that's my fault. I don't adhere to any normal standard. "x2" just means both parameters are the same - integers - which saves a miniscule amount of typing.

    For public methods, I do like to make a brief mention of parameters since that helps to explain how a class should be used without having to delve too deeply. I don't bother for private methods on the grounds that if you've go that far into the details of the class you'll have figured out what's getting passed around.

    I may well need some peer review...

  12. #37
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Actually it was my fault because I changed the code and didn't at least delete the comments. I don't do block header comments and usually only comment where it is not clear from the code why something is being done how it is being done.

    Also neves, you seem to have gone off on multiple interfaces before getting some code to solve the first one.
    Christopher

  13. #38
    SitePoint Addict timvw's Avatar
    Join Date
    Jan 2005
    Location
    Belgium
    Posts
    354
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If you like OOP...

    PHP Code:
    public interface operation
    {
      public function 
    operate($operand1$operand2);
      public function 
    getoperator();
    }

    public class 
    AddOperation implements operation
    {
      public function 
    getOperator()
      {
         return 
    "+";
      }
      
      public function 
    operate($operand1$operand2)
      {
         return 
    $operand1 $operand2;
      }
    }

    public class 
    MultiplyOperation implements operation
    {
      public function 
    getOperator()
      {
         return 
    "x";
      }
      
      public function 
    operate($operand1$operand2)
      {
         return 
    $operand1 $operand2;
      }
    }


    public class 
    calculator
    {
      private 
    $operators;
      
      public 
    __constructor()
      {
         
    $this->operators = array();
      }

      public 
    addOperator($operator)
      {
        
    $this->operators[] = $operator;
      }

      public 
    calculate($operation$operand1$operand2)
      {
        foreach(
    $this->operators as $operator)
        {
           if (
    $operator->getOperator() == $operation)
           {
              return 
    $operator->operate($operand1$operand2);
           }
        }
        return 
    "-E-";
      }
    }

    class 
    CalculatorFactory
    {
      public static function 
    getCalculator()
      {
         
    $calculator = new Calculator();
         
    $calculator->addOperator(new AddOperation());
         
    $calculator->addOperator(new MultiplyOperation());
         return 
    $calculator;
      }
    }

    $calculator CalculatorFactory::getCalculator();

    echo 
    $calculator->calculate("+"510); 
    Last edited by timvw; Jun 3, 2005 at 01:13.

  14. #39
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think timvw has got is going. Rather than a Factory, I think it should use the Command pattern because it is going to be an Input Controller to dispatch based on the operation and pass the operands to the proper Command.
    Christopher

  15. #40
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hmm, I take the view their are only 2 base commands. One that ands the button pressed to a string buffer (for the digits and operators excluding =) and = which evaluates the string buffer.

    Having a addOperator or negativeOperator looks fraught with problems, as button meanings can vary in meaning based on their context. Minus (-) can be subtract or unary minus etc.

  16. #41
    SitePoint Addict timvw's Avatar
    Join Date
    Jan 2005
    Location
    Belgium
    Posts
    354
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    All i did was give some (bloated) OOP for the Model

    I suppose the OP will accept complete expressions. So he would need a parser/lexer to find the parts in the expression, before they can be calculated by the calculator.

    How he binds the text field that accepts the expressions to the lexer and/or calculator is completely up to him. This also means that the html could provide completely different "signs/buttons/whatever" ...

  17. #42
    SitePoint Addict been's Avatar
    Join Date
    May 2002
    Location
    Gent, Belgium
    Posts
    284
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I find it amusing that, although we're in TFFKAAPF (The Forum Formerly Known As Advanced PHP Forum - I'm licking my keyboard as I type, pitching a high "aaoow" and shaking my behind in the most funkiest of ways ), no one seems to care about 'PHP application design', everybody just posts some code, without tests, even McGruff :shocked: !

    There are but a few business rules, no use cases and everybody has jumped into the implementation perspective allmost instantly, totally ignoring the analysis and design perspectives.

    Whether this is because the problem domain appears to be simple, or that this is just 'the php way of doing things', I don't know, but if we want to adhere some educational value to this thread, shouldn't we be doing some analysis first?

    We need to do this analysis so that people reading this thread will know exactly what we're building, we need to have a firm grasp of the problem domain.

    But, most likely, the problem domain is exactly the errr problem: For us developers, problem domains exist because something or someone has a need of some kind that he/she/it thinks can be filled in by having some software build.
    We owe it to ourselves to assess those needs (Pragmatic Programmer Chapter7, "before the project" - Tip 51 - "Don't Gather requirements, dig for them").

    In this case, no one actually needs a calculator, the problem presented to us is hypothetical at best and as such, it can only spawn hypothetical solutions... at best, most likely 'the calculator' will never be build.

    It's becoming painfully clear that the thing missing here is definition; definition of the problem, definition of the needs, definition of usage,...

    So, here's my feable attempt at formulating and defining the problem, business rules and an EUCM.
    Please note that my experience in this is on the verge of non-existant and I appreciate any comments, remarks, tips, guidance etc...

    ------------------------------------------------------------------------
    Situation:
    ------------------------------------------------------------------------
    We're building a 'Calculator'
    By 'Calculator' we mean a reusable software component.

    The Calculator will support the 4 major operations:
    - addition
    - substraction
    - multiplication
    - division
    It is very likely that a need for more operations will exist in the future

    The Calculator will support only simple decimal numbers (integers and floats, no complex numbers, no hexadecimals or octals)
    It is unlikely that complex numbers will be supported in the future
    It is unlikely that any other base will be supported (decimal only)

    The Calculator will adhere to the mathematical order of operations.

    The Calculator will correctly support brackets.

    The results that the Calculator produces must be mathematically correct. Rounding rules taken into account (see BR04)

    The Calculator must be accessible from within different contexts.
    Initially, a web context and a command line context must be supported, but it must be possible to reuse the Calculator with a minimum of effort. In particular, the Calculator itself must not be changed to be able to support a different context.

    To demonstrate the use and reuse of the Calculator, we will also build a web- and a command line application

    The language of implementation should be PHP, after all, this is TFFKAAPF



    ------------------------------------------------------------------------
    Business Rules
    ------------------------------------------------------------------------
    * BR01 - Order of operations.
    The Calculator has to respect the order of operations as they are defined in basic mathematics:
    1. Brackets
    2. multiplication / division
    3. addition / substraction
    This BR will change if new operations are introduced

    * BR02 - Only Decimal based Integers and Floats
    The Calculator will support both integer and float numbers.

    * BR03 - Number size
    The Calculator will support numbers that have 12 digits at most.
    Integers that are bigger than 12 digits will not be handled by the Calculator.
    Floats will be handled using 13 digits internally to round according to BR04

    * BR04 - Rounding floats
    When presented with a floating point number, the Calculator will internally use 13 digits to round to the 12th one (everything after the 13th digit is truncated)
    rounding rules: (m = 12th digit, n = 13th digit)
    if n >= 5 then m = m + 1



    ------------------------------------------------------------------------
    EUCM
    ------------------------------------------------------------------------

    ------------------------------------------------------------------------
    EUC01 - Calculating an expression
    ------------------------------------------------------------------------
    Actors: User, Calculator
    Pre conditions: -
    Basic path:
    1. User presents the Calculator with a mathematical expression
    2. The Calculator validates the expression
    3. The Calculator evaluates the expression
    4. The Calculator returns the result of the expression
    5. Use case ends
    Post condition: The result is calculated

    Alternative A: User doesn't want to do calculations
    1. The user can decide to quit using the Calculator at any time
    2. Use case ends
    Post condition: no change

    Alternative B: Expression is not understood
    3. The Calculator cannot make sense of the expression presented
    4. The Calculator notifies the user of this
    5. Use case ends
    Post condition: no change

    Alternative C: Result is too big.
    4. The result would exceed 12 digits
    5. The Calculator notifies the user that it cannot handle the expression
    6. use case ends
    Post condition: no change
    That's about it, for the moment, this is by no means definitive of course, it's just an attempt at analysis of a hypothetical problem.
    I have tried very hard to stay in analysis perspective and not to use technical terms that are not a part of the problem domain (forms, buttons, clicks, ... they don't belong in analysis perspective).
    What would be nice, is that this analysis could grow to something everybody agrees on, only then go on with the design, for example with a SUCM, from there build some tests, and then, finally, to some actual code.

    Ignore all this at will by the way, I have a Java assignment that has to be finished by monday, then exams, so I'm afraid this pathetic attempt is all I have time for at the moment.
    Per
    Everything
    works on a PowerPoint slide

  18. #43
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Nice post Per.

    'The Calculator' is basically a function which takes in a string, and outputs a number or an error message; plus some code to generate the string.

    Now, that string->number conversion is imo the model, and will be the same regardless of what type of interface we have. The interface could be as simple or as complex as you like; it could just be a text box with a submit button, or it could look like a real calculator having lots of buttons and a readout - in which case you'll need some RESTful state and so on. I'm not sure which label you want to put on that part of the code

    Douglas
    Hello World

  19. #44
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by timvw
    All i did was give some (bloated) OOP for the Model

    I suppose the OP will accept complete expressions. So he would need a parser/lexer to find the parts in the expression, before they can be calculated by the calculator.

    How he binds the text field that accepts the expressions to the lexer and/or calculator is completely up to him. This also means that the html could provide completely different "signs/buttons/whatever" ...
    But is that bloated OOP really neccessary? You've seemingly dived into the middle of problem, without actually thinking why you need it.

    I'd use a compiler-compiler. This allows me to write the parser & evaluator very simply.. (this is using lemon)

    Code:
    %left PLUS MINUS.
    %left ASTERIX FORWARDSLASH.
    
    expr			::= expression(X).		{ $this->result = X; }
    
    expression(A)	::= OPENPARENTHESIS expression(X) CLOSEPARENTHESIS.		{ A = X; }
    expression(A)	::= expression(X) PLUS expression(Y).					{ A = X + Y; }
    expression(A)	::= expression(X) MINUS expression(Y).					{ A = X - Y; }
    expression(A)	::= expression(X) ASTERIX expression(Y).				{ A = X * Y; }
    expression(A)	::= expression(X) FORWARDSLASH expression(Y).			{ if (Y != 0) { A = X / Y; } else throw new DivideByZeroException(); }
    
    expression(A)	::= NUMBER(X).											{ A = X; }
    This contains the grammar of the expressions I need to parse in 16 lines. I can easly add more operations, adjust operator priorities. Even at a later date change from a direct evaluating parser to one that does construct an abstract syntax tree of the expression.

  20. #45
    SitePoint Addict timvw's Avatar
    Join Date
    Jan 2005
    Location
    Belgium
    Posts
    354
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It seemed ppl where asking for an OO approach to the problem, so i typed what came in my mind..

    As i said in my first posting in this thread: A simple call to GNU bc is probably how i would implement my solution.. I don't suffer the not invented here problem...

  21. #46
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think the original question was looking for an example of how classes in the MVC layers might fit together and in particular how to identify the model. For this, the simplest possible model is best. I'd stick with add and subtract.

  22. #47
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I agree. Perhaps the place to start is to define what part of the calculator app is the M, the V and the C.
    Christopher

  23. #48
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ok, I'll try to make a helpful contribution to this thread. Been has done a great job already of stating the requirements for the calculator. In there he has not stated any assumptions about how the calculator would be implemented, which is a good thing.

    As far as I could see/read, there isn't really consensus on whether the interface of this app should have buttons for each operation or whether the app should parse an expression.

    I believe that both methods can lead to a rather simple division of model, view and controller code.

    Case 1: expression parsing
    If we choose this method, the model, parsing the expression, would be rather difficult.

    I have just finished a Java project for a very simple expression parser, as part of a software design course. It can parse expressions like (( X + 30 ) / 2.5) - 30.

    We created a Parser class that can transform the string above into an Expression object. Class Expression had subclasses like AddExpression, DivideExpression, etc. The AdditionModel class that was posted earlier in this thread is similar to this. For this project there would also be classes like SquareRootExpression etc. These expression classes would obviously be part of the model.

    But since this excercise is not about how to parse an expression, let's assume that we simply have a Parser that can parse an expression.

    The app would need one input controller that would call the parser with the input string, catches any possible errors thrown by the parser, and then creates a view that displays the result of the expression and the expression itself.

    [b]Case 2: buttons for each operation[/b
    I think the model would be something like the Calculator class posted by McGruff. The input controller would look at the button that was pressed and apply the operation on the calculator and choose a view to write the result back to the browser.

    So, what do we choose?

  24. #49
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think your Case 2 is more interesting from the MVC point of view because it is more about dispatching. Going the Case 1 focuses on the expression parser which, unlike dispatching, is application specific.
    Christopher

  25. #50
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    Brazil,Maringá-PR
    Posts
    128
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I find it amusing that, although we're in TFFKAAPF (The Forum Formerly Known As Advanced PHP Forum - I'm licking my keyboard as I type, pitching a high "aaoow" and shaking my behind in the most funkiest of ways ), no one seems to care about 'PHP application design', everybody just posts some code, without tests, even McGruff :shocked: !
    Totaly agree This thread is all about that!

    ------------------------------------------------------------------------
    Situation:
    ------------------------------------------------------------------------
    We're building a 'Calculator'
    By 'Calculator' we mean a reusable software component.

    The Calculator will support the 4 major operations:
    - addition
    - substraction
    - multiplication
    - division
    It is very likely that a need for more operations will exist in the future
    The model, should be flexible enougth, to be easy add new operations(unary and binary ones).

    The Calculator will support only simple decimal numbers (integers and floats, no complex numbers, no hexadecimals or octals)
    It is unlikely that complex numbers will be supported in the future
    It is unlikely that any other base will be supported (decimal only)
    IMHO the binary and hexadecimal support, can be easly added using conversors between binary=>decimal and vice-verse. It's good the calculator has this support, cause I want to know where it would fit in MVC.

    The Calculator will adhere to the mathematical order of operations.

    The Calculator will correctly support brackets.
    no need for brackets, only binary and unary simple operations

    Adding more definitions(those are just for learning):
    The code must follow PHP5 new OOP features
    Design Patterns are very welcome
    Louse Coupling and code reuse is required!
    (MVC doens't all about that!? )

    I think your Case 2 is more interesting from the MVC point of view because it is more about dispatching. Going the Case 1 focuses on the expression parser which, unlike dispatching, is application specific.
    Agree. The control of button press, is like the navigation in a site links. It looks like a state machine.

    Ren, can you explain how works your grammar?


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •