MVC renderizando

[criatividade zero 17]

estou finalizando o sistema e pintou uma pequena duvida / consulta

o controller recebe a requisição válida e vai renderizar a view de acordo com a requisição:

mobile, desktop, ajax

 

então deveria conter uma view para cada requisição?

view/mobile/pagina.view.php

view/desktop/pagina.view.php

view/ajax/pagina.view.php

 

alguem tem outra opção?

[Thales Caricati 3]

Cara, eu uso assim ( quando necessário ) e acho bem mais organizado.

 

Acho que neste caso seria uma boa opção .

[criatividade zero 17]

desktop e mobile são estruturas diferentes, inclusive o model é exclusivo

renderizar para uma requisição ajax seria para a internacionalização e janelas

 

por isso essas 3 pastas distintas

tb acho que é mais pratico, mas qualquer outra ideia é bem vinda :)

[Bruno Augusto 417]

Nesse caso seu, eu, extremista, fresco e paranóico como eu sou, criaria (mini-)aplicações distintas para cada tipo de requisição.

 

Assim, cada "módulo" teri seus próprio Controllers, Models e Views, sem pastas e mais pastas separando...

[visitante_php 0]

depende muito do padrao q você esta usando...qual padrao você esta usando: page controller, action controller, front controller, o q exatamente?

[Henrique Barcelos 290]

desktop e mobile são estruturas diferentes, inclusive o model é exclusivo

Se o model é exclusivo, então são aplicações diferentes... Separe...

[André Severino 3]

Olá Bruno também faço deste jeito que você disse, mas no caso já fugiria do padrão MVC e entraria no HMVC, certo ?

 

:thumbsup:

[Bruno Augusto 417]

Mais ou menos.

 

Pelo que eu entendo de HMVC, cada pequena parte de um site é um MVC próprio.

 

Suponhamos que na Home do site tem Busca, Newsletter, Noticias.

 

Daí tem-se um trio de diretórios Controllers, Models e Views para cada seção, cada uma num diretório-pai. Assim você pode reutilizar a mesma mini-aplicação de contato em qualquer aplicação maior que exigir um formulário de contato.

 

Eu espero que esse conceito que eu aprendi esteja equivocado, pois pelo menos pra mim não faz sentido.

 

Veja, mesmo que o CSS e os possíveis JavaScripts requeridos pelo formulário de contato fiquem fora do diretório das aplicações, ainda assim o HTML de tal formulário vai puxar um CSS/JavaScript na tag HEAD.

 

Oras, se vai puxar X.css, para estilizar para o o site X.com, como que iria haver reaproveitamento para o Y.com, sendo que esse usa uma folha de estilos totalmente diferente?

 

Até que se prove (ou se explique :ermm: ) em contrário, prefiro muito mais criar um ContactController (Controller) e contact.phtml (View) para cada aplicação que requeira um simples formulário de contato, do que ter que fazer mil e uma gambiarras para ter 100% de reaproveitamento de um módulo do site.

[André Severino 3]

Então, não sei se entendi direito, mas caso você use o HMVC, você pode sim reaproveitar esse X.css na pagina Y.html :P

 

No caso voce apenas separaria as mini-app's para organização, mas isso não quer dizer que elas não podem manter contato entre si, você pode ter um controller/modelo/view apenas para contato.

 

Por exemplo, eu tenho no diretório web-files/js/global um arquivo jquery.js, se o usuário acessar a app X eu faço o include do jquery para ele, e nas outras apps faço o include do mesmo arquivo, se de repente eu quero usar uma nova function dele por exemplo a prop(), eu apenas atualizo o antigo 1.4 pelo novo 1.6 no diretorio js/global e já roda em todas as apps...

 

O mesmo vale para controllers/models/views eu tenho acesso em tudo...

 

Abaixo uma imagem de uma print que tirei rapidinho apenas para ilustrar:

 

http://imageshack.us/photo/my-images/163/estrutura.jpg/

 

:thumbsup:

[Bruno Augusto 417]

Então, mas (eu espero estar enganado), a definição de HMVC que eu vi pregava que CADA pequeno módulo deve ser independente do sistema como um todo, mas ao mesmo tempo utilizável neste todo, entende?

 

Eu também faço como você, cada seção do site/aplicação em um diretório e, em cada diretório o trip Controllers, Models e Views.

 

Fora dessa árvore tenho o diretório Public com os arquivos públicos (dããã) que podem ser incluídos tanto nos templates do Portal como do Painel Administrativo, por exemplo, que são módulos distintos.

 

mas a idéia que pude captar de HMVC é bizarra demais. Gostaria de entender melhor também.

[Henrique Barcelos 290]

O HMVC é um MVC modular, subdividido em módulos (desejadamente) independentes.

 

Enquanto no MVC, um certo grau de acoplamento entre os componentes da aplicação é tolerado, no HMVC ele deve ser mínimo, pra não dizer inexistente.

 

Na prática, não muita muita coisa. Imagine que utilizando HMVC seria mais fácil incorporar funcionalidades a sua aplicação.

Temos um site e desejamos adicionar um módulo de enquetes. Com o HMVC, criamos esse módulo e o integramos ao nosso sistema 'automaticamente'.

O caminho inverso também é verdadeiro. Se desejamos remover as enquetes do site, basta remover o módulo.

 

Entretanto, isso é meio 'utópico', no mínimo, você tem que mexer no mecanismo de templates ou no HTML para que ele não tente incluir mais as enquetes na página.

É possível desenvolver um "módulo gerenciador de módulos" que faça isso automaticamente pra você, mas não é lá tão trivial.

[André Severino 3]

Então Bruno a idéia que tive 'aparentemente' é igual essa sua, também não sei direito se estou no caminho certo ou errado :(

 

Enquanto no MVC, um certo grau de acoplamento entre os componentes da aplicação é tolerado, no HMVC ele deve ser mínimo, pra não dizer inexistente.

 

Temos um site e desejamos adicionar um módulo de enquetes. Com o HMVC, criamos esse módulo e o integramos ao nosso sistema 'automaticamente'.

 

Então, vamos supor(exemplo que aconteceu comigo), tenho um módulo (artigos), nesse módulo posto artigos e etc...

De repente pediram para integrar no sistema um módulo de newsletter, ok. Criei um novo módulo newsletter.

 

Se eu fosse seguir o acomplamento baixo que eles pedem eu iria ter que copiar/colar funções do artigo, porque ?

 

Nos requisitos do sistemas tinha a opção de enviar newsletter usando noticias postadas no sistema de artigos... Para não reescrever usei alguns models do artigos.

 

'Mas André, se o cliente não comprar o artigos, não funciona o Newsletter?'

Res: Funciona sim, porque quando o cliente compra o sistema as dependencias vai junto, assim como toda a estrutura do banco de dados, o que acontece é que tenho um controlador responsável por fazer verificação em todos os módulos que o cliente tem ou não acesso.

 

Edit: Não tinha visto o que o Rick tinha digitado então estou complementando aqui.

[criatividade zero 17]

Nesse caso seu, eu, extremista, fresco e paranóico como eu sou, criaria (mini-)aplicações distintas para cada tipo de requisição.

 

Assim, cada "módulo" teri seus próprio Controllers, Models e Views, sem pastas e mais pastas separando...

 

você diz essa arvore?

 

desktop
|- controller
   |- noticia
|- model
   |- noticia
|- view
   |- noticia


mobile
|- controller
   |- noticia
|- model
   |- noticia
|- view
   |- noticia

 

achei esse artigo sobre HMVC

http://techportal.ibuildings.com/2010/02/22/scaling-web-applications-with-hmvc/

[Bruno Augusto 417]

você diz essa arvore?

Isso mesmo.

 

Mas pelo que vi no artigo que você passou, para adicionar um pouco de ordem na bagunça, um nível a mais deveria ser adicionado, separando todos os mini-módulos de cada módulo maior.

 

achei esse artigo sobre HMVC

http://techportal.ibuildings.com/2010/02/22/scaling-web-applications-with-hmvc/

Muito interessante, pena quele preferiu se basear no Kohana pra explicar. pRa quem não usa pode não sentir algo tão tátil.

 

Mas eu acho que clareou um pouco minhas idéias. Eu percebi pelo artigo que o HMVC não é um Padrão de Projeto, mas sim uma ramificação da forma como se aplica o MVC tradicional.

 

Numa aplicação MVC temos um Controller para cada "grupo" de ações:

 

UsersController :seta: Tudo sobre Usuários

SettingsControllers :seta: Tudo sobre Configurações do Sistema

 

E por aí vai.

 

E no HMVC temos a mesma coisa, porém ainda mais fracionado:

 

Settings/Controllers/SystemController :seta: Tudo sobre as Configurações referente ao núcleo do sistema

 

Settings/Controllers/DateTimeController :seta: Tudo sobre as Configurações referentes à Data & Hora

 

E por aí vai.

 

Mas o grande truque mesmo está no SettingsController que ao invés de simplesmente:

 

SettingsController extends AbstractController {

   public function mainAction() {
       // Exibe Template com todos os tipos de configuração possíveis
   }
}

Passa a ser mais elaborado:

 

SettingsController extends AbstractController {

   public function mainAction() {

       $systemRequest = new Request( 'request/uri/for/system/settings' );

       $systemResponse = $systemRequest -> send() -> getResponse();

       if( $systemResponse -> status == 200 ) {

           $this -> getResponse() -> appendBody( $systemResponse -> getBody() );
       }

       // Repete para cada módulo existente
   }
}

Assim perde-se a dependência inter-aplicações pois, se amanhã ou depois você tiver uma aplicação onde tem-se diversas opções de configurações mas Data & Hora não está dentre elas, você pode simplesmente deletar o diretório referente à ese MVC e nem mexer no SettingsController pois este só vai adicionar algo na View atual se o módulo existir.

 

Acertei?

[Henrique Barcelos 290]

Assim perde-se a dependência inter-aplicações pois, se amanhã ou depois você tiver uma aplicação onde tem-se diversas opções de configurações mas Data & Hora não está dentre elas, você pode simplesmente deletar o diretório referente à ese MVC e nem mexer no SettingsController pois este só vai adicionar algo na View atual se o módulo existir.

 

Acertei?

É mais ou menos isso...

 

Na prática, o buraco é mais embaixo. É difícil desenvolver um código TOTALMENTE desacoplado...

 

Numa aplicação MVC temos um Controller para cada "grupo" de ações:

 

UsersController Tudo sobre Usuários

SettingsControllers Tudo sobre Configurações do Sistema

 

E por aí vai.

 

E no HMVC temos a mesma coisa, porém ainda mais fracionado:

A separação ainda é a mesma, +/- uma tríade MVC para cada entidade.

 

A diferença, do meu ponto de vista, é que no MVC clássico, não se emula requisições como no HMVC. Apenas UM controller é chamado durante a execução. Se é necessário fazer alguma interação entre entidades diferentes, fazemos isso no Model.

 

Como eu não tenho um mecanismo de View ainda, apenas vou incluindo o HTML, também não há a necessidade de chamar mais de uma View diferente.

 

A verdade é que o MVC já é meio 'hierárquico', se não não faria sentido. O HMVC é apenas um jeito diferente de tratar requisições que dizem respeito a múltiplos módulos...

[criatividade zero 17]

estava olhando mais alguns artigos...

uns fazem referencia ao dispositivo desktop e mobile como phone e ipad

 

 

desktop

|- controller, model, view

ipad

|- controller, model, view

phone

|- controller, model, view

 

 

essas divisões procedem?

[Bruno Augusto 417]

Eu acho que não procede, não.

 

No meu sistema, se eu fosse considerar uma versão mobile (que não é o caso no momento) e houvesse REALMENTE a necessidade de separar um MVC para cada dispositivo, eu nem precisaria separar.

 

Com o meu sistema de roteamento, posso ter uma aplicação Mobile e, dentro de Mobile/Controllers posso ter, iOSCOntroller, AndroidController, XYZ851RedeCulturaSaoPauloController ( :lol: ) e etc.

 

Todos esses Controllers usufruiriam das mesmas Models, então não haveria necessidade de criar um MVC para cada SO.

 

Até mesmo porque imagina o cenário:

 

Mobile/iPhone/Models/iPhone/Controllers/ClientsController.php

<< usar >>

Mobile/iPhone/Models/Clients.php

 

Mobile/iPhone/Models/Android/Controllers/ClientsController.php

<< usar >>

Mobile/Android/Models/Clients.php

 

Ambas as Models Clients.php são idênticas. Por que duplicá-las?

 

Só que também ficaria esquisito:

 

Mobile/iPhone/Models/Android/Controllers/ClientsController.php

<< usar >>

Mobile/Android/Models/Clients.php

[Henrique Barcelos 290]

Não cara... No model e no controller você não mexe... A única coisa que muda é a View.

Mesmo sendo ambientes diferente, ainda são baseados em requisições HTTP, não importa se foi feita de um computador comum, smartphone ou iPhone/iPad...

[criatividade zero 17]

Não cara... No model e no controller você não mexe... A única coisa que muda é a View.

Mesmo sendo ambientes diferente, ainda são baseados em requisições HTTP, não importa se foi feita de um computador comum, smartphone ou iPhone/iPad...

para desktop, posso exibir uma determinada noticia, comentários, ultimas noticias

para mobile, vou apenas mostar a noticia sem os outros itens

 

não é apenas a view que muda

se mantiver o model e o controller iguais, terei um monte de recurso indo pelo ralo

[Henrique Barcelos 290]

Hmmm... nesse caso, recomendo mexer apenas no controller, mas deixar o model intacto...

Pesquise sobre o padrão Strategy, pode lhe ser útil...