Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
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?
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 :)
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...
depende muito do padrao q você esta usando...qual padrao você esta usando: page controller, action controller, front controller, o q exatamente?
desktop e mobile são estruturas diferentes, inclusive o model é exclusivo
Se o model é exclusivo, então são aplicações diferentes... Separe...
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:
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.
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:
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.
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.
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.
>
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/
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?
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 /applications/core/interface/imageproxy/imageproxy.php?img=../../public/style_emoticons/default/seta.gif&key=058873f4af1f8160cd90fb7294eecb71d754a4b8aa5228db73740f46d21ea768" alt="seta.gif" /> Tudo sobre Usuários
SettingsControllers /applications/core/interface/imageproxy/imageproxy.php?img=../../public/style_emoticons/default/seta.gif&key=058873f4af1f8160cd90fb7294eecb71d754a4b8aa5228db73740f46d21ea768" alt="seta.gif" /> 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...
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?
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
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...
>
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
Hmmm... nesse caso, recomendo mexer apenas no controller, mas deixar o model intacto...
Pesquise sobre o padrão Strategy, pode lhe ser útil...
mesmo assim deveria haver uma divisão maior
hj a duvida é implementar mobile x desktop, mas os dispositivos são variados, ha consoles, tv que agora navega
tv e desktop podem entrar na mesma lista, afina, basta usar uma tela como monitor e o resultado é o mesmo
mas ipad, smatphone, console, celular, e afins, vão entrar todos como mobile?
o que nao for um pc desktop, pode ser considerado mobile...mesmo ipad q nam eh celular, nem tv, nem pc, nem netbook, ah, notebook e netbook nao entram como mobile... XD
tv e desktop podem entrar na mesma lista, afina, basta usar uma tela como monitor e o resultado é o mesmo
Criatividade você diz isso diante do tamanho, ou da engine do navegador da tv ? Nunca usei o navegador na tv, já vi ele sendo utilizado + assim nunca usei. Ele renderiza bem igual o chrome e tals ? Ou tem problemas alá ie6 ?
abraços
>
Criatividade você diz isso diante do tamanho, ou da engine do navegador da tv ? Nunca usei o navegador na tv, já vi ele sendo utilizado + assim nunca usei. Ele renderiza bem igual o chrome e tals ? Ou tem problemas alá ie6 ?
pela engine mesmo, o tamanho da tela é o de menos
ela pode ser ligada no pc, ou ser o dispositivo de acesso
Cara, eu uso assim ( quando necessário ) e acho bem mais organizado.
Acho que neste caso seria uma boa opção .