Грязный или чистый код в Visualforce page?

Привет.

Хотел бы услышать ваше мнение по такому вопросу.

Salesforce предоставляет мощный инструмент Visualforce с огромным набором apex тегов. Но в то же время мы можем использовать и просто html, что во многом делает разработку проще и понятнее.

Что вы думаете по этому поводу. Используете ли вы исключительно apex теги или применяете их только случае необходимости использовать функционал Visualforce.

Dmitry Shnyrev

Привет.

Хотел бы услышать ваше мнение по такому вопросу.

Salesforce предоставляет мощный инструмент Visualforce с огромным набором apex тегов. Но в то же время мы можем использовать и просто html, что во многом делает разработку проще и понятнее.

Что вы думаете по этому поводу. Используете ли вы исключительно apex теги или применяете их только случае необходимости использовать функционал Visualforce.

Привет
В целом apex теги иногда вызывают некоторые сложности в построении страницы, в основном это расположение текста где то приходиться дорисовать пустой блок что бы увидеть текст там где его ожидаешь.

Но я все таки рекомендую использовать apex теги, при парсе страницы накладывается куча стилей на html блоки и если вдруг saleforce решит поменять дизайн вы будете следовать общему стилю.

Tusha

Привет :)

В целом apex теги иногда вызывают некоторые сложности в построении страницы, в основном это расположение текста где то приходиться дорисовать пустой блок что бы увидеть текст там где его ожидаешь. 

Но я все таки рекомендую использовать apex теги, при парсе страницы накладывается куча стилей на html блоки и если вдруг saleforce решит поменять дизайн вы будете следовать общему стилю.

Tusha, спасибо за ваше мнение.

Действительно, использование apex тегов оправдано и даже необходимо при тесной интеграции со стилями Salesforce.
Но мне, например, в работе больше приходится сталкиваться с разработкой уникальных в плане стилей, не похожих на стандартные SF, страниц. Это в основном касается разработки customer или partner portals в корпоративном стиле заказчика. Тут активно привлекаем к работе верстальщиков и javascript программистов. Представляете их ужас, когда они видят исходный код visualforce страницы :).

Обычно такие "корпоративные" страницы начинаются так <apex:page controller="..." showHeader="false" standardStylesheets="false" >

Dmitry Shnyrev

Tusha, спасибо за ваше мнение. 

Действительно, использование apex тегов оправдано и даже необходимо при тесной интеграции со стилями Salesforce.
Но мне, например, в работе больше приходится сталкиваться с разработкой уникальных в плане стилей, не похожих на стандартные SF,  страниц. Это в основном касается разработки customer или partner portals в корпоративном стиле заказчика. Тут активно привлекаем к работе верстальщиков и javascript программистов. Представляете их ужас, когда они видят исходный код visualforce страницы :).

Обычно такие "корпоративные" страницы начинаются так :)
<apex:page controller="..."   showHeader="false"   standardStylesheets="false" >

Подниму древную тему HTML VS APEX:TAGs

некоторые апекс теги кажутся полными аналогами HTML тегов.
и вот один пример:

<apex:outputLink value="/servlet/servlet.FileDownload?file={!a.ID}" >My attachment</apex:outputLink>
<a href="/servlet/servlet.FileDownload?file={!a.ID}">My attachment</a>

и вроде все одинаково.
Но последний не работает на сайтовой странице, так как там после базового УРЛ есть еще путь, а первый работает как в Орге, так и на сайте. Большая разница.
Как говорится, "черт сидит в мелочах".

Den Brown

Подниму древную тему [b]HTML VS APEX:TAGs[/b]

некоторые апекс теги кажутся полными аналогами HTML тегов.
и вот один пример:

[code]<apex:outputLink value="/servlet/servlet.FileDownload?file={!a.ID}" >My attachment</apex:outputLink>

<a href="/servlet/servlet.FileDownload?file={!a.ID}">My attachment</a>[/code]

и вроде все одинаково.
Но последний не работает на сайтовой странице, так как там после базового УРЛ есть еще путь, а первый работает как в Орге, так и на сайте. Большая разница. 
Как говорится, "черт сидит в мелочах".

Спасибо что поделился информацией по этому вопросу. Мне будет полезно Запомню.

Dmitry Shnyrev

Спасибо что поделился информацией по этому вопросу. Мне будет полезно :) Запомню.

Den Brown

Подниму древную тему HTML VS APEX:TAGs
некоторые апекс теги кажутся полными аналогами HTML тегов.
и вот один пример:
<apex:outputLink value="/servlet/servlet.FileDownload?file={!a.ID}" >My attachment</apex:outputLink>
<a href="/servlet/servlet.FileDownload?file={!a.ID}">My attachment</a>
и вроде все одинаково.
Но последний не работает на сайтовой странице, так как там после базового УРЛ есть еще путь, а первый работает как в Орге, так и на сайте. Большая разница.
Как говорится, "черт сидит в мелочах".

Может все таки не стоит использовать ссылки данного вида, а начать использовать URLFOR?

Gres

[quote="Den Brown"]Подниму древную тему [b]HTML VS APEX:TAGs[/b]

некоторые апекс теги кажутся полными аналогами HTML тегов.
и вот один пример:

[code]<apex:outputLink value="/servlet/servlet.FileDownload?file={!a.ID}" >My attachment</apex:outputLink>

<a href="/servlet/servlet.FileDownload?file={!a.ID}">My attachment</a>[/code]

и вроде все одинаково.
Но последний не работает на сайтовой странице, так как там после базового УРЛ есть еще путь, а первый работает как в Орге, так и на сайте. Большая разница. 
Как говорится, "черт сидит в мелочах".[/quote]
Может все таки не стоит использовать ссылки данного вида, а начать использовать URLFOR?

Gres

Может все таки не стоит использовать ссылки данного вида, а начать использовать URLFOR?

Well, URLFOR это еще один важный момент. Думаю у других больше опыта использовыания URLFOR, так что буду рад если продолжите тему улучшение и "де-хардкодофикации" ссылок.

Den Brown

[quote="Gres"]Может все таки не стоит использовать ссылки данного вида, а начать использовать URLFOR?[/quote]

Well, URLFOR это еще один важный момент. Думаю у других больше опыта использовыания URLFOR, так что буду рад если продолжите тему улучшение и "де-хардкодофикации" ссылок.

Не знаю, сколько не пытался с URLFOR подружиться в начале своей карьеры, но так он и не прижился. Знаю что им удобно делать ссылки на стандартные view, edit, list страницы объектов. Но если лазить по кастомным страницам {!$Page...} хватает выше крыши. Честно не сталкивался с задачей когда без URLFOR нельзя обойтись (хотя для свяких static resource использую на автомате, копипастом)

Dmitry Shnyrev

Не знаю, сколько не пытался с URLFOR подружиться в начале своей карьеры, но так он и не прижился. Знаю что им удобно делать ссылки на стандартные view, edit, list страницы объектов. Но если лазить по кастомным страницам {!$Page...} хватает выше крыши. Честно не сталкивался с задачей когда без URLFOR нельзя обойтись (хотя для свяких static resource использую на автомате, копипастом)