tourze / diy-page-bundle
广告位、装修
Installs: 0
Dependents: 0
Suggesters: 0
Security: 0
Stars: 0
Watchers: 1
Forks: 0
Open Issues: 0
Type:symfony-bundle
Requires
- php: ^8.1
- doctrine/collections: ^2.3
- doctrine/dbal: ^4.0
- doctrine/doctrine-bundle: ^2.13
- doctrine/doctrine-fixtures-bundle: ^4.0
- doctrine/orm: ^3.0
- doctrine/persistence: ^3.1 || ^4
- knplabs/knp-menu: ^3.7
- monolog/monolog: ^3.1
- nesbot/carbon: ^2.72 || ^3
- psr/log: ^3|^2|^1
- symfony/config: ^6.4
- symfony/dependency-injection: ^6.4
- symfony/doctrine-bridge: ^6.4
- symfony/event-dispatcher-contracts: ^2.5 | ^3
- symfony/expression-language: ^6.4
- symfony/http-kernel: ^6.4
- symfony/security-bundle: ^6.4
- symfony/security-core: ^6.4
- symfony/serializer: ^6.4
- tourze/arrayable: 0.0.*
- tourze/bundle-dependency: 0.0.*
- tourze/doctrine-async-bundle: 0.1.*
- tourze/doctrine-indexed-bundle: 0.0.*
- tourze/doctrine-ip-bundle: 0.0.*
- tourze/doctrine-snowflake-bundle: 0.1.*
- tourze/doctrine-timestamp-bundle: 0.0.*
- tourze/doctrine-track-bundle: 0.1.*
- tourze/doctrine-user-bundle: 0.0.*
- tourze/easy-admin-attribute: 0.1.*
- tourze/easy-admin-menu-bundle: 0.1.*
- tourze/json-rpc-cache-bundle: 0.1.*
- tourze/json-rpc-core: 0.0.*
- tourze/symfony-ecol-bundle: 0.1.*
- tourze/symfony-schedule-entity-clean-bundle: 0.1.*
- yiisoft/arrays: ^3
Requires (Dev)
- phpstan/phpstan: ^2.1
- phpunit/phpunit: ^10.0
This package is auto-updated.
Last update: 2025-06-03 10:57:17 UTC
README
基于 Page、Block、Element 构建的模块
设计参考:
TODO
- 针对地区设定不同的广告信息
- 针对用户登记设定不同的广告信息
- 不同时段不同的广告信息
关于装修与专题的方案
装修:
之前我们的装修的设计想法主要是通用性,以及期望是减少体积(尽可能不增加定制页面),例如一个单页面,服务端可以DIY不同的组件组合,前端只需要根据配置去渲染不同的组件,但是按照这种做法,我们会发现前端对于组件的维护就比较艰难了,逻辑很多,这样也会带来页面渲染的性能问题。 后来APP项目做了重构,所有模块都拆分出来了,那么对于一些简单的定制页面还是可以单独维护的。装修的页面应该是一个通用且简单的页面,如果涉及太多的业务逻辑的就不太适合装修的了,我们之前是对一些比较偏业务的页面也实现了装修能力,但本质上我们解决仅仅是代码复用的问题。 装修的组件应该尽可能的少业务,只负责渲染,纯粹一些,可以参考下竞品的装修设计,那这样的话,装修模块要梳理一次的了。
专题
目前我们的专题是主要是渲染一些图片块,定义期望图片产生的行为。我觉得跟装修还是有区别的,如果专题仅仅是负责图片的渲染,那么可以合并到装修模块,但是很多时候,一场活动的专题,往往会期望产生很多的不同的行为,例如:各自环境的调整问题、一些定制的能力。 如果合并到装修的话,一个通用的ImageItem 组件就要处理很多的逻辑了且有些可能是解决不了的,例如专题活动往往会有时效性?如果合并到装修如何理解?另外合并到装修,图片的跳转行为又要多很多的约定了,就不单单是跳转路径的问题。如果后续需要对专题进行报表统计,合并到装修也并不好处理。 如果没有一个很好的设计方案,暂时不太建议合并到装,而是应该拆分出来。如果强行把专题合并到装修也不是不可以,简单就是把专题的能力移植到装修中去,做好各种兼容。