Announcement

Collapse
No announcement yet.

The mod community will embrace vB5 Connect.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    Originally posted by soniceffect View Post
    Just because MVC is not used doesnt make it wrong?
    Hmm, yeah, it makes it wrong, if you advertise MVC as one of the key new features of vB 5 Connect.

    Comment


    • #62
      Originally posted by soniceffect View Post
      Surely anything else is a different model and not MVC as apposed to cludging. Just because MVC is not used doesnt make it wrong?
      vBulletin 5 Connect introduces a new MVC Architecture designed to separate the business logic from the presentation logic more than ever before. This will allow vBulletin 5 to be quickly and easily extended as we bring new features to the software.
      So, of course someone is drawing an illogical line between standard MVC and what vBulletin clearly states is a new architecture. Selective reading makes for easy formation of arguments.

      Comment


      • #63
        Originally posted by s.molinari View Post
        So the new "vB MVC" architecture is probably similar to their definition of what a beta version is too, right?

        MVC is a standard. You can't make it newer. It is what it is and if you don't follow the standard, you have something else and you can't really call it MVC. Maybe it should be called vB KOM architecture?

        And it is a shame we even have to bicker about this instead of reading about what the system's new architecture is really all about. The manual needs a lot of work.

        Scott
        I respectfully disagree. HTML was a standard too. It's been made newer several times. Some still embrace HTML. Others XHTML. Still others HTML5. To each his or her own.

        I do fully concur the manual is far beyond sub-par. It borders upon useless, particularly in this regard. But I would also venture the average end user cares more about "Can I make it do this?" than they care about the underlying architecture that causes the software to make it do what they want.

        Comment


        • #64
          Originally posted by AlexanderT View Post
          Hmm, yeah, it makes it wrong, if you advertise MVC as one of the key new features of vB 5 Connect.
          Fair enough, hadnt been on there and seen that tbh.

          Originally posted by ProSportsForums View Post
          So, of course someone is drawing an illogical line between standard MVC and what vBulletin clearly states is a new architecture. Selective reading makes for easy formation of arguments.
          If you look closely you will see a question mark, making it a question not an arguement. I was actually asking the question.
          Husky Owners Forum - For all Siberian Husky Owners

          Comment


          • #65
            Originally posted by soniceffect View Post
            If you look closely you will see a question mark, making it a question not an arguement. I was actually asking the question.
            I know you were. That's why I attempted to clarify what the vBulletin manual actually states. They are not advertising standard MVC as a new feature. They are advertising a new architecture of MVC.

            Comment


            • #66
              Originally posted by ProSportsForums View Post
              I know you were. That's why I attempted to clarify what the vBulletin manual actually states. They are not advertising standard MVC as a new feature. They are advertising a new architecture of MVC.
              Ohhhh I see ... my bad, long day LOL
              Husky Owners Forum - For all Siberian Husky Owners

              Comment


              • #67
                Originally posted by s.molinari View Post
                Ok, rethinking I'll take that back. Yes, a standard can be improved and once it is improved, it could be considered "newer". But adding the possibility to use PHP in vB's template system doesn't necessarily mean something good either and if there is any way to override controllers (like manipulating data, not needed for a certain view) with this possibility, then it will be used to cludge.

                And again, it is all hypothetical, without documentation I am certainly not going to take the time at this point to go learn how it works by digging through the code. I am sure many other admins/devs feel this way too. So, getting the thread back on track, without good docs, it's going to be that bit harder for add-on devs to embrace vB5.

                Scott
                Im sure there is plenty in the beta tester forums and im sure it will be made public in due course.
                Selling my BigBoard GamerzNeeds.net/forums Threads: 193 502, Posts: 1 540 045, Members: 718 566 It is listed here http://forums.digitalpoint.com/showt...3#post18297060

                Comment


                • #68
                  Originally posted by Wayne Luke View Post
                  What notice about Vertical Response and where?
                  The short answer to this is I can't remember; I think it was in one of the email announcements or marketing press releases.

                  Either way, when the CMS and Calendar come along I'll take a look at vB5. If the Vertical Response bit hasn't changed much I won't be using it; MailChimp works much better.

                  Comment


                  • #69
                    Originally posted by s.molinari View Post
                    Ok, rethinking I'll take that back. Yes, a standard can be improved and once it is improved, it could be considered "newer". But adding the possibility to use PHP in vB's template system doesn't necessarily mean something good either and if there is any way to override controllers (like manipulating data, not needed for a certain view) with this possibility, then it will be used to cludge.
                    To an extent, you've always been able to use some PHP in vBulletin's templates. That is what template conditionals and all those $variables are. We just encapsulate the PHP into a different form. Can even manipulate the conditional code to set variables and alter the output of the page if you know what you're doing. With vBulletin 4, we started encapsulating the variables ({vb:var}, {vb:raw}, {vb:url}, {vbhrase}, etc...} to make the product more secure. Kind of a template within a template within a templating script language.

                    In vBulletin 5 you cannot write direct PHP in the templates. This is no different than before. However there new template tags that give more control. These include:

                    {vb:data} - Allows you to pull data from a specific API method.
                    {vb:set} - Allows you to set a variable for that template only.
                    {vb:template} - Pulls in a different template instead of using a direct PHP variable.
                    {vb:strcat} - Used to concatenate two strings usually phrases.
                    {vb:strrepeat} - Allows you to repeat a string X times.

                    There are a few others as well to load javascript, load CSS, etc... As with all previous {functions} and <tags>, these are rendered into their appropriate PHP when the template is saved. This has been the case since conditionals were added in 3.X and the syntax expanded in the 4.X series.

                    The main reason for these new tools is that the Presentation layer, where the templates are rendered, does not have direct access to the database. It needs to go through the Core API layer to get that information.
                    Last edited by Wayne Luke; Wed 24th Oct '12, 10:04am.
                    Translations provided by Google.

                    Wayne Luke
                    The Rabid Badger - a vBulletin Cloud demonstration site.
                    vBulletin 5 API - Full / Mobile
                    Vote for your favorite feature requests and the bugs you want to see fixed.

                    Comment


                    • #70
                      Originally posted by s.molinari View Post
                      MVC is a standard.
                      I don't believe I'd go so far as to call it a standard. I believe I called it a "design paradigm" - what I meant by that was that it's more of a guideline to accomplish something, but you still have a choice in implementation.

                      The fact that vB allows API calls to be made in the Presentation layer is a huge boon to developers. It allows for streamlining code to only run array building code if/when it's needed, etc - as opposed to needing to prepare it all beforehand.

                      vB does still adhere to the MVC principle, it contains all the same elements of xF - API & Library (Model), Template Rendering / Presentation (View), Controller & Route (Controller). You just have additional choice to render templates into vars that are returned from an API call, if you so choose. But if you do (and I have), it's you who violates MVC, not vB

                      In short, vB5 does not make it extraordinarily difficult to violate MVC if for who knows what reason you need to. This is nothing but a boon to developers, it does no harm whatsoever.

                      Originally posted by s.molinari View Post
                      Ok, then all is well and I guess this text from Fillip was just misinterpreted.
                      Sorry for it being ambiguous, I'm very much not skilled at explaining my thoughts so others who can't read my mind can understand me. I was indeed referring to the {vb:data} API call syntax - IIRC there's no equiv in xF.
                      www.Dragonbyte-tech.com

                      Comment


                      • #71
                        Well this thread turned out to be a total success!

                        Thanks for the explanation guys!
                        The 47 Ronin Gaming - www.47r-squad.com

                        Comment

                        Related Topics

                        Collapse

                        Working...
                        X